Error Handling

[Uriah Piddle]

Hi Gang,

I read a blog by Karl Sequin on catching errors and it has been sinking in
and I can see the merits. The gist of it is that you really should catch
only those errors that you can actually resolve in code and let the rest of
them (the vast majority) blindly bubble up to the global error catcher. Here
is the blog:
http://codebetter.com/blogs/karlseguin/archive/2006/04/05/142355.aspx.

I infer from this that you should not really be writing a whole lot of Try
Catch Finally blocks -- pretty much just cleaning up with Finally or Using
statemtnts and letting nature take its course.

I really can't think of a reason not to follow this method but I was
wondering if I'm missing something.

Thanks for any ideas.

Steve

 

[Peter Bradley]

Yup. It's what we do, more or less. The important thing is to ensure that
you catch every exception in the end and do something with it like redirect
to a global error page that says something nice and user friendly and allows
the user either to get back into the application, or abort. As it happens,
we do this in global.asax.

The most unprofessional thing I see on asp.net sites are the default error
messages that result from uncaught exceptions. They are not user friendly
and they give away far too much information about how your application is
structured.

Just my 2c


Peter

 

[Karl Seguin [MVP]]

My $0.02 might not be worth too much since you already know my opinion. But
in that blog post, I quote (and link to) a really good interview by Anders
Hejlberg - C#'s lead architect. The link is
http://www.artima.com/intv/handcuffs.html and he talks about the point in
question on page 2.

I think you'll be hard pressed to find someone reasonable who'll disagree.
Even Java zealots have started to turn around.

Karl