Re: YHO about Try-Catch use.

rhaazy wrote:
I am looking for some feedback on using try catch statements.

They're like champagne: great in moderation, but for some reason people insist on bringing it into situations where it doesn't add anything to the occasion, just because they think they should.

Usually when I start a project I use them for everything, but stop
using them as often after the "meat n' potatos" of the project is
finished.

Doing it the other way around has a much better chance of success. If you're using exception handlers for "everything", does that mean you're writing bad code that usually fails? Do you feel like you can do something about it when it does or do you just feel like you've acknowledged that bad things can happen?

An exception handler is a tool for error recovery. You first think about what sort of error recovery you're going to need and how to best achieve that, then you write code that keeps it in mind. This will involve strategic use of exception handlers, but the stress is on "strategic".

I am thinking it would be useful to at least have a blanket try-catch
to surround all of the code, and add more to aid in debugging and
catching specific exceptions.

Putting a try-catch at the highest level is often helpful for two reasons. One is logging, the other is to make sure the exception doesn't leak outside your system. For example, if you're writing a web service, you don't want exceptions to be passed back to the client as-is -- they can expose embarrassing internals or even sensitive customer information. So you catch them and return something appropriate, while keeping the full details of what went wrong in a log for yourself.

Exception handlers for debugging are bogus. Your debugger already stops at unhandled exceptions, and you can configure it to stop at handled ones too. You can even configure what exception types it should pay attention to. You'll have all the information you need at your fingertips. Adding exception handlers for debugging will just interfere with actual error handling code.

Wrapping exceptions and re-throwing them with more information, on the other hand ("this went wrong because of that"), is a better idea, but supporting debugging should not be the goal in that. Debugging is what you do when things go wrong and you can still fix them. Your application eventually has to work then things go wrong and you can't fix them, and your exceptions should be just as good then. So adding them to have more comprehensive error reporting is good, but that's not specific to debugging.

There are a few places where you *know* you will need an exception handler because the operation simply cannot be made to always succeed, you just don't necessarily know *where*. For example, if you're executing a query on a database server, this will fail somewhere someday because database servers are not as available as the CPU your code is running on. So you can't get around catching an SqlException or a DbException somewhere[*], you just have to pick the right spot. The right spot will be the one where whatever application-specific action you were trying to do with that query can be failed or retried as a whole.

Error recovery is a big topic, and the proper use of exceptions even more so, so you've asked a nice question for big discussions.

[*]This is not true. You can in fact get away with not catching any exceptions at all, but this is approach is not trivial to apply. See http://dslab.epfl.ch/pubs/crashonly/crashonly.pdf, for example. And even then, it still pays off to have an outer exception handler.

--
J.
.

Relevant Pages

  • Re: YHO about Try-Catch use.
    ... great in moderation, but for some reason people ... An exception handler is a tool for error recovery. ... use of exception handlers, but the stress is on "strategic". ... Exception handlers for debugging are bogus. ...
    (microsoft.public.dotnet.general)
  • Re: Secure C library
    ... > That's the only real advantage in maintaining the current call stack. ... If the callback returns, then the ... >> terminate the process or to throw an exception. ... Also note that with nested exception handlers, ...
    (comp.std.c)
  • Re: Exception management question...
    ... > are actually events generated by different libraries that wrap execution ... >> AppDomain.UnhandledException or to all three Global Exception Handlers? ... >> correctly written so it doesn't need any exception handling! ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: jad gibt Fehlermeldung aus
    ... Not all exception handlers will be ... Der Code ist auch nur sehr schwer zu gebrauchen. ...
    (de.comp.lang.java)
  • Re: SBS 2003 BOSD (mrxdav.sys), Help Needed Please
    ... Cris Hanna [SBS - MVP] ... MVPs do not work for Microsoft ... Use!analyze -v to get detailed debugging information. ... exception record and context record. ...
    (microsoft.public.windows.server.sbs)