Error handling best practice

[fawkes]

We're writing an in-house program that will also be referenced from other programs and I'm wondering about the best practice for error handling.

The program throws exceptions, is it best to handle these within the program or could we leave it for other programs to pick these errors up, if we leave it for other programs then should we use delegates for the exceptions?

I know it seems strange to ask about not handling the errors in the program but it is really a dll with an interface to collect some registry settings and to avoid the dll-hell problems.

 

[chrissie1]

You should throw really bad programs and let the view deal with it. Some errors (the ones that need intervention from the IT department or admin) just get logged. I don't think users can be bothered with error message except when it ruins their experience. You don't want 500 errors saying the connection has been lost. 1 will do and the rest get logged or the app closes.

Christiaan Baes
Belgium

My Blog
"In a system where you can define a factor as part of a third factor, you need another layer to check the main layer in case the second layer is not the base unit." - jrbarnett

 

[SiriusBlackOp]

This is one of those things that you have to decide. What do you want and expect from it?

All I can say is that you should sit down and plan it... then keep to the plan. It is very frustrating when a program inconsistently handles similar exceptions.

If it is really just a DLL, then you should probably just throw them and let the referencing application/service handle them.

Senior Software Developer

http://www.scoutsft.com

 

[fawkes]

Thanks for the reply, I'll go down the route of throwing the exceptions.

One more thing, do I need to use delegates, is it preferable?

 

[chrissie1]

I don't think you need delegates.

Christiaan Baes
Belgium

My Blog
"In a system where you can define a factor as part of a third factor, you need another layer to check the main layer in case the second layer is not the base unit." - jrbarnett

 

[ThatRickGuy]

At my last gig we had a who error system in place. When ever an exception was encountered, all of the relevant information was written to the database. If that database call failed, it would fail over to an XML file on the network. All of the would happen in a centralized method that was called from any of the exception handling block.

We then had an ASP.Net reporting web page that allowed us to pull up the errors for any user, process, or execution of the program. It was really nice for checking the results of the nightly processes to make sure none of the printers jammed or if someone had crammed bad data into the database.

If you go that route, I would also recommend recording the app version. It makes for some handy reporting when you are trying to show progress to the project manager.

As for the User side of things. Give the users 1 'in your face' message, and everything else gets warned in a less work stopping way. Just give the user one message to let them know what happened and whether or not the system will continue to operate correctly.

For example, I'm using an out dated version of Toad for Oracle, and because of our firewall my connection drops every hour. Any time I try to close the Toad after that connection drops, I have to deal with between 3 and 15 error messages, send back prompts, and other annoying crap and I have to try to close the app again at least 3 times. This is the wrong way.

-Rick

VB.Net Forum forum796 forum855 ASP.NET Forum
I believe in killer coding ninja monkeys.