Try-catch everywhere!
-
hey folks, i've been reading TDWTF for a few years now... and i really hope this won't make my code end up here someday. that's why i'm asking.
is encasing every single bit of loading in try-catch and logging any catches a wtf, or just good practise? i'm asking this because i'm currently contemplating doing so, out of frustration with ogre's tendency to crash if anything's out of order.
-
I'm working with an API right now that catches all errors thrown by my code and just eats them. doesn't rethrow, doesn't send them to STDERR, just eats them, so I HAVE to put everything in a try/catch
grrrrr....
But to answer your question, I dunno. I tend to use try/catch pretty liberally because most of the API code (especially when connecting to a database) declare a lot of Exceptions. You don't want those Exceptions getting up to the UI layer. Catch them and spit something out to a errlog file with a date/time, unless you can handle the exception more gracefully. Even if the app crashes because of the exception, you'll be happier with the log than a user telling you about an obscure error message.
-
@belgariontheking said:
I'm working with an API right now that catches all errors thrown by my code and just eats them. doesn't rethrow, doesn't send them to STDERR, just eats them, so I HAVE to put everything in a try/catch
grrrrr....
But to answer your question, I dunno. I tend to use try/catch pretty liberally because most of the API code (especially when connecting to a database) declare a lot of Exceptions. You don't want those Exceptions getting up to the UI layer. Catch them and spit something out to a errlog file with a date/time, unless you can handle the exception more gracefully. Even if the app crashes because of the exception, you'll be happier with the log than a user telling you about an obscure error message.
I'd be happier with a user complaining about error messages than a user complaining because they got invalid or incomplete information back and made a mistake because of it, and all you have to say is, "well, if you would have checked the error logs you would have seen this."
-
Some rules of thumb -
Only catch when you can and need to clean up, then re-throw.
If you have a defined interface then you may convert an exception to a generic version (e.g. SQL exception to 'Data Layer Exception'). Then do so and re-throw.
If you catch, always log. Almost always re-throw unless you can deal with the error. If not, clean up then re-throw
Try to keep the stack trace going - use language/platform features.
Never convert an exception to a return value.
Never show errors via message boxes or other GUI facilities in your data or business layer. UI should try to do something using lower layers & report the result protected by try/catch.
If the UI catches an error in the back end then the user should see 'something went wrong - we will fix it' not 'Sql blah blah...variable not bound..' etc. Log the full error in an event log or elsewhere in the back end. The user does not need to know the gory details.
-
@LoztInSpace said:
If the UI catches an error in the back end then the user should see 'something went wrong - we will fix it' not 'Sql blah blah...variable not bound..' etc. Log the full error in an event log or elsewhere in the back end. The user does not need to know the gory details.
On a similar note.... it's sometimes easier to tell you what not to do, rather than what to do.
Short story: in general, don't let an exception bubble up so far that the language's/framework's default exception handler takes over.
Long story:
Here's a UI example of what not to do: I've seen a GUI C# app fail to catch an exception for a relatively harmless problem, as a result of the user providing invalid input. Since the app didn't catch the exception, the default handler popped up and provided "continue" and "quit" buttons.
At least half of the people I've seen using the app hit the Quit button reflexively, and that turns the harmless problem into a very harmful problem by quitting without saving their work.
This WTF has at least 4 morals:
1. The user's input should have been properly validated in the first place, preventing any exception from being thrown at all, and a useful error message should have popped up.
2. Failing #1, the exception should have been caught at a high level, logged, and a polite generic error message should have come up.
3. Users are endlessly creative in finding bugs in your program, even (especially!) when they're not trying.
4. Given the choice of 2 buttons to click, users will tend to click the wrong one.
