Re: YHO about Try-Catch use.

On Aug 1, 2:33 pm, Jeroen Mostert <jmost...@xxxxxxxxx> wrote:
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. Seehttp://dslab.epfl.ch/pubs/crashonly/crashonly.pdf, for example. And even
then, it still pays off to have an outer exception handler.

--
J.

The situation that bought up this question was an issue with my client
supplying me with bad data. I have to run some sql that performs a
division operation and the denominator is an exchange rate. For some
reason the client sent me some data with some exchange rates set to
0.0000 which makes no sense at all... The only number I should get
thats not an actual exchange rate would be 1.0000. So I got some
divide by zero error that did exactly what you explained, exposed
sensitive data that definately should not be seen, and because of an
error I probably should have tested for, but didn't think to. So I
was debating whether or not to add try-catch to just expose this error
or if I should add it to catch any error. If I add it to catch any
error, than I should add it to the rest of my code too....

Your responses were very informative. I always appreciate the
feedback from the professionals who post on the various google group
programming forums.
.

Relevant Pages

  • 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: YHO about Try-Catch use.
    ... 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". ... Exception handlers for debugging are bogus. ...
    (microsoft.public.dotnet.general)
  • 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)