SURVEY: How are you doing Global Error Handling in ASP.NET

[Jason Kester]

Best I can tell, there are three basic ways you can deal with global
error handling in ASP.NET. Namely:

1. Derive all your pages from a custom Page class, and override
OnError()

2. Specify a custom 500 handler in Web.Config

3. Specify a custom 500 handler in IIS

and I guess you could add:

4. Let them fall through & spit out ugly error messages
I'm curious to see how people are doing it in the real world.
Personally, I've always used option #1, as it seems to offer the most
flexibility, and I'm already using custom Page objects, so it's no
extra work.

I'm asking this because we're getting close to a public BETA release
of Regressor.NET, and am considering adding support for cases 2 and
3. Before I commit the resources though, I'd like to get a feel for
how many people would benefit from it.

I look forward to seeing what people have to say. Thanks for the
help!

Jason Kester
Automated Crash Reporting and Regression Testing for ASP.NET
http://www.regressor.net/

ps. If anybody is interested in becoming a Beta tester for
Regressor.NET, let me know!

[Stefan Kalcher]

Jason Kester schrieb:

Best I can tell, there are three basic ways you can deal with global
error handling in ASP.NET. Namely:

1. Derive all your pages from a custom Page class, and override
OnError()

2. Specify a custom 500 handler in Web.Config

3. Specify a custom 500 handler in IIS

and I guess you could add:

4. Let them fall through & spit out ugly error messages

5. Use global.asax to catch errors

greets,
steve

--
Stefan Kalcher

Programming's just like sex, one mistake, you support it for life.

[Mike Hofer]

On Mar 12, 1:29 am, "Jason Kester" <[e-mail]:

Best I can tell, there are three basic ways you can deal with global
error handling in ASP.NET. Namely:

1. Derive all your pages from a custom Page class, and override
OnError()

2. Specify a custom 500 handler in Web.Config

3. Specify a custom 500 handler in IIS

and I guess you could add:

4. Let them fall through & spit out ugly error messages

I'm curious to see how people are doing it in the real world.
Personally, I've always used option #1, as it seems to offer the most
flexibility, and I'm already using custom Page objects, so it's no
extra work.

I'm asking this because we're getting close to a public BETA release
of Regressor.NET, and am considering adding support for cases 2 and
3. Before I commit the resources though, I'd like to get a feel for
how many people would benefit from it.

I look forward to seeing what people have to say. Thanks for the
help!

Jason Kester
Automated Crash Reporting and Regression Testing for ASP.NEThttp://www.regressor.net/

ps. If anybody is interested in becoming a Beta tester for
Regressor.NET, let me know!

In my application, I do the following:

1.) All of my Web forms derive from a base Page class. OnError is
overridden to handle errors there.

2.) I also handle exceptions in Global.asax, in the event that I've
missed something.

3.) Wherever the default handlers in my base class and/or Global.asax
aren't appropriate, I implement suitable exception handling.

4.) The application has a custom web page, which is itself an aspx
page. Some might have a tough time with that design, but it's
*extremely* stable, and doesn't do anything subject to failure.

5.) Every exception is logged to the database (if possible) and to the
Windows event log.

Yeah. I take 'em very seriously.

[Jason Kester]

I'm also a big fan of the custom Page idea. And I agree that logging
everything is important (that's why we wrote Regressor.NET!) It's
amazing how much you find out about your application when every single
exception gets logged.

Curious though, how many exceptions are you really seeing fall through
to Global.asax? I've seen a few posts on this thread from people that
are using Global.asax as a backup, but personally I've never had a
problem with the overriden OnError in my custom page classes. At
least I've never seen anything fall through in person, but then I
guess I'd never know if anything were slipping through the cracks...

Mike, do you forward crash reports directly to your bug tracking
software?

Jason Kester
Automated Crash Reporting and Regression Testing for ASP.NET
http://www.regressor.net/

On Mar 12, 11:04 am, "Mike Hofer" <[e-mail]:

In my application, I do the following:

1.) All of my Web forms derive from a base Page class. OnError is
overridden to handle errors there.

2.) I also handle exceptions in Global.asax, in the event that I've
missed something.

3.) Wherever the default handlers in my base class and/or Global.asax
aren't appropriate, I implement suitable exception handling.

4.) The application has a custom web page, which is itself an aspx
page. Some might have a tough time with that design, but it's
*extremely* stable, and doesn't do anything subject to failure.

5.) Every exception is logged to the database (if possible) and to the
Windows event log.

Yeah. I take 'em very seriously.- Hide quoted text -

- Show quoted text -

[Mike Hofer]

On Mar 12, 3:04 pm, "Jason Kester" <[e-mail]:

I'm also a big fan of the custom Page idea. And I agree that logging
everything is important (that's why we wrote Regressor.NET!) It's
amazing how much you find out about your application when every single
exception gets logged.

Curious though, how many exceptions are you really seeing fall through
to Global.asax? I've seen a few posts on this thread from people that
are using Global.asax as a backup, but personally I've never had a
problem with the overriden OnError in my custom page classes. At
least I've never seen anything fall through in person, but then I
guess I'd never know if anything were slipping through the cracks...

Mike, do you forward crash reports directly to your bug tracking
software?

Jason Kester
Automated Crash Reporting and Regression Testing for ASP.NEThttp://www.regressor.net/

On Mar 12, 11:04 am, "Mike Hofer" <[e-mail]:

In my application, I do the following:

1.) All of my Web forms derive from a base Page class. OnError is
overridden to handle errors there.

2.) I also handle exceptions in Global.asax, in the event that I've
missed something.

3.) Wherever the default handlers in my base class and/or Global.asax
aren't appropriate, I implement suitable exception handling.

4.) The application has a custom web page, which is itself an aspx
page. Some might have a tough time with that design, but it's
*extremely* stable, and doesn't do anything subject to failure.

5.) Every exception is logged to the database (if possible) and to the
Windows event log.

Yeah. I take 'em very seriously.- Hide quoted text -

- Show quoted text -- Hide quoted text -

- Show quoted text -

Unfortunately, no, but that's due to the disconnected nature of our
system. The bug tracking database is housed here, at the software
shop, and the software itself is located on the production server at
the client -- in a different state, on a secure system, behind a
firewall, and to which we have no access. We are not permitted any
access to that system, due to security concerns. (It's a government
agency.)

The database contains an error log table; we are fortunate enough to
be able to receive backups of the database for data mining purposes,
and we mine that table to monitor exceptions for stuff that we missed.
I'm pleased to report that our unhandled exception rate is *extremely*
low.

We use BugTracker.NET here to track defects. It's rudimentary, but it
gets the job done for what we need. If we were able to write a secure
Web service to shuffle the data across the wire to BugTracker, I would
definitely be interested in doing that, but I don't think the client
will approve that any time in the near future. (Money is always a big
concern, and they have other things they want to get done at this
point in time. Since we are doing things pretty well "status quo,"
they're likely going to take the point of view that we can survive as
we are until it becomes a truly pressing concern. And if it ever came
to that, it would speak volumes about my code quality--they'd likely
need to hire a new developer, and I'd be brushing off my resume.)

[Mike Hofer]

On Mar 12, 3:04 pm, "Jason Kester" <[e-mail]:

I'm also a big fan of the custom Page idea. And I agree that logging
everything is important (that's why we wrote Regressor.NET!) It's
amazing how much you find out about your application when every single
exception gets logged.

Curious though, how many exceptions are you really seeing fall through
to Global.asax? I've seen a few posts on this thread from people that
are using Global.asax as a backup, but personally I've never had a
problem with the overriden OnError in my custom page classes. At
least I've never seen anything fall through in person, but then I
guess I'd never know if anything were slipping through the cracks...

Mike, do you forward crash reports directly to your bug tracking
software?

Jason Kester
Automated Crash Reporting and Regression Testing for ASP.NEThttp://www.regressor.net/

On Mar 12, 11:04 am, "Mike Hofer" <[e-mail]:

In my application, I do the following:

1.) All of my Web forms derive from a base Page class. OnError is
overridden to handle errors there.

2.) I also handle exceptions in Global.asax, in the event that I've
missed something.

3.) Wherever the default handlers in my base class and/or Global.asax
aren't appropriate, I implement suitable exception handling.

4.) The application has a custom web page, which is itself an aspx
page. Some might have a tough time with that design, but it's
*extremely* stable, and doesn't do anything subject to failure.

5.) Every exception is logged to the database (if possible) and to the
Windows event log.

Yeah. I take 'em very seriously.- Hide quoted text -

- Show quoted text -- Hide quoted text -

- Show quoted text -

In regards to your questions regarding exceptions that fall through to
global.asax, I've only seen this a handful of times at best. But when
they did, I was *very* thankful it was there. Since we log everything
to our database, data mining helps us to uncover those unhandled
exceptions and treat them as critical defects that require immediate
resolution.

[Jason Kester]

Yeah, it's tough having to work in the real world. Best practices
have a way of slipping through the cracks at most places.

Here at Expat Software we use Fogbugz, so we have the option of
sending out crash report distress calls either by Email or via HTTP.
Either way, Fogbugz will automatically log a new case for us.

Regardless, it sounds like you're well ahead of the game. I suspect
that most shops have never considered logging exceptions at all!

Jason Kester
Automated Crash Reporting and Regression Testing for ASP.NET
http://www.regressor.net/


On Mar 12, 12:14 pm, "Mike Hofer" <[e-mail]:

>
Unfortunately, no, but that's due to the disconnected nature of our
system. The bug tracking database is housed here, at the software
shop, and the software itself is located on the production server at
the client -- in a different state, on a secure system, behind a
firewall, and to which we have no access. We are not permitted any
access to that system, due to security concerns. (It's a government
agency.)

[Jason Kester]

Yeah, it's tough having to work in the real world. Best practices
have a way of slipping through the cracks at most places.

Here at Expat Software we use Fogbugz, so we have the option of
sending out crash report distress calls either by Email or via HTTP.
Either way, Fogbugz will automatically log a new case for us.

Regardless, it sounds like you're well ahead of the game. I suspect
that most shops have never considered logging exceptions at all!

Jason Kester
Automated Crash Reporting and Regression Testing for ASP.NET
http://www.regressor.net/


On Mar 12, 12:14 pm, "Mike Hofer" <[e-mail]:

>
Unfortunately, no, but that's due to the disconnected nature of our
system. The bug tracking database is housed here, at the software
shop, and the software itself is located on the production server at
the client -- in a different state, on a secure system, behind a
firewall, and to which we have no access. We are not permitted any
access to that system, due to security concerns. (It's a government
agency.)