Jump to content
  • Advertisement
Sign in to follow this  
HexDump

Exceptions and Return codes (yes sorry, agian).

This topic is 3894 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi all, I have read lota of information about exceptions, lota of threads here about them and return codes, but I can´t decide what to do. It seems the best thing is to mix Exceptions and return codes, and user Exceptions only for really important errors (pretty hard to decide what are they). So, Could anyone expose its point of view, and give any example about how to use all this in correct way?. Best practices, etc... Thanks in advance, HexDump.

Share this post


Link to post
Share on other sites
Advertisement
That link is a good one, and Fruny's link within that link is also good.

I agree with Sit in the link that the most important thing is to be consistent. I throw a lot more in Java than in C++ for example. Personally, I don't buy into the 'Exceptions only for exceptional circumstances'. If you have an error in a function that the caller needs to know about, that's exceptional enough for me. Though that doesn't always call for an exception.

The other options aren't really great to me either. A bool usually isn't too useful and will often get ignored leading to bugs. I'll use these for something like Container.Remove(Item) where the success might be useful to know, but ignoring it won't be the end of the world.

Returning null/error-value on failure is similar, but (imo) better since the caller can't really ignore the return value since that's often what they want in the first place.

A static errno style error code sucks, and should be avoided.

A returned error code is (imo) not so good either. It leads to a lot of case statements where-ever the method is used, or a catchall "handle this error code" method which makes stuff unclear and icky. Plus it somewhat defeats the purpose of a function (take input, produce output).


But that assumes the caller needs to know about the method's failure. That isn't always the case, and (imo) should be the preferred design. If a player doesn't have permission to do something in-game for example, you can handle that within the method (perhaps with a configurable event) or just no-op and log it.

But yeah, check out those links. People far more seasoned and intelligent than I might think otherwise (and have better reasons why).

Share this post


Link to post
Share on other sites
To me, a really good time to use an exception is when you have a lot of stack unwinding to do. Cleans up the code nicely.

Share this post


Link to post
Share on other sites
Hi again,


ReadTFM, mate, don´t understand what you want to mean :). Why would you do stack unwinding by yourself?

Another question that goes paralell to this question: Where should a catch go, I mean, I don´t feel like writing try/catch for every everror I want to check, do anybody know (I don´t know if this a stupid question) where catches should go? (I have read they execptions should be using for centralized processing of errors, so, there should be some key places where put them).


Thanks in advance,
HexDump.

Share this post


Link to post
Share on other sites
Quote:
Original post by HexDump
Another question that goes paralell to this question: Where should a catch go, I mean, I don´t feel like writing try/catch for every everror I want to check, do anybody know (I don´t know if this a stupid question) where catches should go?


Always place a catch statement in a place where you can handle the exception that you catch.

Share this post


Link to post
Share on other sites
Quote:
ReadTFM, mate, don´t understand what you want to mean :). Why would you do stack unwinding by yourself?


Sometimes a failure needs to be propagated up several levels. Instead of having the three or four or whatever functions test for return codes and then return an error code themselves, it's easier to throw an exception that will jump through the stack all the way up to the top level caller.

Share this post


Link to post
Share on other sites
ToohrVyk, sure you said something pretty logical for all of you, but could you put any example? it doesn´t need to be code, just a practical example, because I think put a catch in every try won´t be the right way to go.

ReadTFM, ok, undestood :).

Thanks in advance,
HexDUmp.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!