Exceptions and Return codes (yes sorry, agian).
Author
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.
Author
Heheeh, you know thi is impossible :), not everything depends on the programmer.
HexDump.
HexDump.
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).
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).
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.
Author
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.
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.
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.
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.
Author
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.
ReadTFM, ok, undestood :).
Thanks in advance,
HexDUmp.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
