SDL_Surface* myFunction() {

/* code for creating the surface...
*********
*/ 
int tryOnce = 0;

if(tempSurface != nullptr) {
   // all is good
   return tempSurface;
} else if(tryOnce < 1) {
   ++tryOnce;
   myFunction();
} else {
   SDL_Log("log error");
   throw "caught error... exiting";
}
                      

Hello,

I wrote a simple program.

It returns surfaces in several functions , but I want to check to see the surface is not a nullptr before returning it and if it is ,

call the same function once more to try to load the image to the surface or whatever, and  if that fails to throw an exception which

will exit the game.  
Is this a bad way to do it , it seems to excessive to end the game but I'm a beginner and really don't want to get too deep into everything yet.

?

thanks

Your code has a bug. The tryOnce variable is local to the function. If tempSurface == nullptr, and you call the function again (in the else if), the new function call will have its own tryOnce variable -- which is initialized to 0. These two tryOnce variables are not the same variables, they just have the same name.

If you want this behavior, you might be better off using a for loop or similar.

Regarding exceptions, there's a thread here you might find interesting:

Thanks I read the topic about exceptions , so they are discouraged altogether ?

should I just test with the if/ else part of the code, I understand the bug you meant.  A for loop would work but I'm still not sure if it makes sense to try to load the function again , and how many times to try , it seems very vague and like bad practice?

Should I otherwise just add:

if (tempSurface!=nullptr) { return tempSurface;}

else throw "some exception occurred ";

or is this remaining code pointless beginners junk ?thnks

3 minutes ago, anotherme said:

Thanks I read the topic about exceptions , so they are discouraged altogether ?

should I just test with the if/ else part of the code

if (tempSurface!=nullptr) { return tempSurface;}

else throw "some exception occurred ";

 

or is this pointless beginners junk ?thnks

Personally, I don't use exceptions. Partly because that's what I'm used to and the coding guidelines at work, and partially because I don't feel they add a lot to the stuff I'm working on.

Others feel differently, and use them.

Like most things, exceptions are something you should know about. It's a tool, to be used when it makes sense. But like most tools, sometimes they aren't useful for the particular problem you're working on right now -- a hammer can be an awesome tool, but I wouldn't use it to wash a window.

so I should do nothing to error check if a surface is a nullptr  either ? 

I thought doing that makes sense at least ?  but if it's a nullptr what should I do then ?

if I leave the if/else with the throw it's acceptable code at least ? thanks

You should definitely error check. Using/dereferencing a null pointer is never a good thing.

If it fails, there's probably not a lot you can do in this case anyway, so you might probably just as well print a message and crash. The only option I can think of right now is that you might possibly try creating the surface with different settings, but I don't remember SDL stuff well enough to say anything more specific.

There's also a broader reply I want to give here.

If you try to create an SDL_Surface and it fails, you're in one of 2 situations:

• You are out of system resources in some way - like system memory, or GPU texture memory. Trying again will not succeed because you'll still be out of resources.
• You are doing something wrong, like passing the wrong parameters. Trying again will not succeed because those parameters will still be incorrect.

As such there is almost never a time when, after calling a function and seeing it fail, you'd want to call it again. So don't do that.

In this situation I don't think it matters whether you check for a null pointer or whether you throw an exception; if you couldn't create a graphic then the game is in a bad state and you probably can't proceed, so you'll almost certainly want to end the program immediately (after logging the nature of the problem, so you can diagnose it).