How to make good use of exceptions?
Author
Hello.
Im trying to make more use of exceptions rather then return codes in my programs. I know how they work and all. What im not so sure about is how to make good use of them. When to use them. How to design your exception classes. When to catch exceptions and when to just re throw them.
In short general good practice in using exceptions.
Anyone know a good resource for that?
Thanks in advance.
A word of wisdom:
"Don't try hard to use exceptions. Using return values is enough 99% of the time. Exceptions should be used only in exceptional circumstances." - Me.
My guess is that exception handling is something that you have just discovered?
ace
"Don't try hard to use exceptions. Using return values is enough 99% of the time. Exceptions should be used only in exceptional circumstances." - Me.
My guess is that exception handling is something that you have just discovered?
ace
When i first learned of Exceptions i felt that they were really awesome, and can completely solve all of the worlds problems (maybe taking it a bit far, but at least solve some of my own code problems :))
As its all worked out, i dont often use exceptions. They definitely have their place and are certaintly an effective tool when used correctly - but im just more comfortable using error codes the majority of the time.
Anyway, to try and answer your questions - Exceptions should only really be used to indicate an exceptional circumstance. In the sense that, if something could potentially go wrong that you as the programmer have little control over (running out of memory, missing files) then you might want to throw an exception. Where to catch it depends on your overall code structure, but often its the calling code that would catch it immediately rather than re-throw.
Dont feel like having discovered exceptions you must start using them in your code immediately. My current project is around 5,000 lines of code so far and im not sure iv even used any exceptions at all.
As its all worked out, i dont often use exceptions. They definitely have their place and are certaintly an effective tool when used correctly - but im just more comfortable using error codes the majority of the time.
Anyway, to try and answer your questions - Exceptions should only really be used to indicate an exceptional circumstance. In the sense that, if something could potentially go wrong that you as the programmer have little control over (running out of memory, missing files) then you might want to throw an exception. Where to catch it depends on your overall code structure, but often its the calling code that would catch it immediately rather than re-throw.
Dont feel like having discovered exceptions you must start using them in your code immediately. My current project is around 5,000 lines of code so far and im not sure iv even used any exceptions at all.
Quote:Original post by ace_lovegrove
A word of wisdom:
"Don't try hard to use exceptions. Using return values is enough 99% of the time. Exceptions should be used only in exceptional circumstances." - Me.
My guess is that exception handling is something that you have just discovered?
ace
Seconded. Never use exceptions for something you expect to happen often, you might use an exception if a resource is missing. You might throw an exception if the GPU don't support shaders, but your game needs 1.1 shaders. You should not throw an exception because the user tried to buy a weapon (s)he couldn't afford because that ain't "exceptional".
A couple of good articles about exceptions:
http://www.freshsources.com/Except1/ALLISON.HTM
http://www.freshsources.com/Except2/ALLISON.HTM
The first introduces what exceptions are (probably not so relevant to you), and the last one talks more about how and when exceptions should be used.
http://www.freshsources.com/Except1/ALLISON.HTM
http://www.freshsources.com/Except2/ALLISON.HTM
The first introduces what exceptions are (probably not so relevant to you), and the last one talks more about how and when exceptions should be used.
>you might use an exception if a resource is missing
Even in this case I wouldn't throw an exception, but rather
fallback to a 'dummy' resource - for textures you could use
a big red cross.
/R
Even in this case I wouldn't throw an exception, but rather
fallback to a 'dummy' resource - for textures you could use
a big red cross.
/R
Use exceptions in exceptional circumstances :-p.
Personally, I rely heavily on exceptions for handling errors. If I buy() an item without the appropriate amount of gold, I would throw an exception. When it's a preformance issue, one can have parallel functions - "attempt_buy" which returns true/false, or "do_i_have_the_money_to_buy" in conjunction.
Boost smart pointer's lib is a good example of this (parallel methods for dealing with such a situation). There are 3 ways that spring to mind of generating a shared pointer for use from a weak pointer, for example:
I use exceptions by default because they tend to be the easiest to use. If profiling reveals a problem, providing a more verbose version which rather obviously needs to have it's return checked (check_my_return_for_errors_or_i_will_punch_you( "he's serious" ), for example)
Personally, I rely heavily on exceptions for handling errors. If I buy() an item without the appropriate amount of gold, I would throw an exception. When it's a preformance issue, one can have parallel functions - "attempt_buy" which returns true/false, or "do_i_have_the_money_to_buy" in conjunction.
Boost smart pointer's lib is a good example of this (parallel methods for dealing with such a situation). There are 3 ways that spring to mind of generating a shared pointer for use from a weak pointer, for example:
boost::weak_ptr< T > weak( ... );//Method 1: Try-or-throwboost::shared_ptr< T > shared1( weak ); //throws bad_weak_ptr on failure//Method 2: Try-then-verifyboost::shared_ptr< T > shared2( weak.lock() ); //shared2.get() == 0 on failureif ( shared2 ) { //..use shared2..}//Method 3: Verify-then-try (dosn't abstract well to multithreaded situations)if ( ! weak.expired() ) { boost::shared_ptr< T > shared( weak ); //could still throw if weak expired between the if statement and this line (e.g. program is multithreaded)}I use exceptions by default because they tend to be the easiest to use. If profiling reveals a problem, providing a more verbose version which rather obviously needs to have it's return checked (check_my_return_for_errors_or_i_will_punch_you( "he's serious" ), for example)
Quote:Original post by Kitt3n
Even in this case I wouldn't throw an exception, but rather
fallback to a 'dummy' resource - for textures you could use
a big red cross.
/R
You would fallback to a 'dummy' resource, does that mean that you won't indicate what you have done in any way. If suddenly the player is one big red-cross he sure wonders what have gone wrong with an exception you can easily catch it, give a message box "this resource is missing, continue with a dummy resource? <Yes> <No>" because there is going to be a message box and we will have to wait for the user anyway performance isn't a problem. If you just put a dummy resource the user have no idea that replacing the player model's texture with a new image in another format didn't work. You could of course check a boolean flag, like FailedToLoadResource or something, but you would have to do this on every resource even though there is less than 1 % chance that the error happens.
So in what case would you use an exception.
Just to echo what was said by everyone else - do not use exceptions to catch an error made on the programmer's behalf.
For instance, if a function was expecting a positive integer, and you passed it a negative one, that is not an exceptional circumstance.
Programming languages such as Java promote the use of exceptions everywhere, but only because it has a decent garbage collector. In C++, it's important for your code to not depend on the use of exceptions, mainly for clarity and maintenance reasons.
Exceptions aren't evil, but just be careful. Clarity over convenience (some might disagree).
For instance, if a function was expecting a positive integer, and you passed it a negative one, that is not an exceptional circumstance.
Programming languages such as Java promote the use of exceptions everywhere, but only because it has a decent garbage collector. In C++, it's important for your code to not depend on the use of exceptions, mainly for clarity and maintenance reasons.
Exceptions aren't evil, but just be careful. Clarity over convenience (some might disagree).
Quote:Original post by Wavarian
Just to echo what was said by everyone else - do not use exceptions to catch an error made on the programmer's behalf.
For instance, if a function was expecting a positive integer, and you passed it a negative one, that is not an exceptional circumstance.
Programming languages such as Java promote the use of exceptions everywhere, but only because it has a decent garbage collector. In C++, it's important for your code to not depend on the use of exceptions, mainly for clarity and maintenance reasons.
Exceptions aren't evil, but just be careful. Clarity over convenience (some might disagree).
Why not to use an exception in that case?
What is so clear about allowing a bug to happen?
If you use an exception to catch this bug, then you can immediatly correct it.
I am sure a player would be happy to discover his character has negative intelligence or something like this.
Exception should be used to catch things you didnt intend that will happen.
You can quote this line.
If something happens in my program that I didnt intend it to happen, such as a red pixel in the bottom left part of the screen, I want to know about it. Even if the program would work with this bug.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
