Error Handlers - Best Pratices 1

[zyonman]

Best Regards for all of you!
i'm creating e new aplication for my company, and one of the things i usualy seen, is that in code almost every body to this:
try
<some code here>
catch exc as Exception
<the error message here>
end try
in some places i've looked i saw only one messagebox with the error message, in other places some guys throw the execption, and there are other guys that create them selves error handlers. i'm trying to figure out what is the best practice to do this, can someone give their opinion?

 

[Craig0201]

You should, if it is a genuine error, throw the exception for the caller to handle. How this is thrown depends on what you are trying to do.

 

[ThatRickGuy]

It matters on how you want to handle the errors.

Lets say you have a data object that handles communication with a database. And you have a business object that calls the data object.

If while retreiving data the data object encounters a TimeOut exception, you will likely want to handle it in the data object and try the command again. If it times out again, you would likely want to throw the exception (or a custom exception) for the business object to handle. The business object could catch the error and send a message to the interface and/or log the error.

I like to handle exceptions in that style. If it is a "correctable" error, handle it as low as possible. If not, throw it back up to the business layer where a standard exception handling method is located to log the error and make a description available to the interface. That way, any exception that would kill a process is handled in the same way and I can easily log, format and display the information.

-Rick

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

 

[SqueakinSweep]

Hmmmmm...my Error handling routines leave a lot to be desired.

Rick..am I right in thinking that each call of Throw, moves one level up the Try-Catch Call Stack?. Or is there something that can be used to trap all errors.


Sweep
...if it works dont mess with it

 

[chrissie1]

Well I will say what I do and don't be disapointed.

My users (and most other users) don't seem to read the error messages. So I stopped showing them. I just log them. But first and foremost I try to avoid getting errors but since you can't forsee everything...

What I like most about users is that they never read the messages even if they get it 10 times in a row and they always tend to forget what they did to get the error and then they ask "can you solve it" answer "Yep no problem give me a gun and it will be solved in 2 seconds".

Christiaan Baes
Belgium

If you want to get an answer read this FAQ faq796-2540
There's no such thing as a winnable war - Sting

 

[ThatRickGuy]

Rick..am I right in thinking that each call of Throw, moves one level up the Try-Catch Call Stack?. Or is there something that can be used to trap all errors.

Sure, just put the whold program in a try/catch block

Anytime you throw an exception it will move up level by level until it is handled. If it never gets handled, the JIT debugger catches it, if no JIT debugger is loaded, the app crashes.

The nice thing about this though is that you can catch specific correctable errors at a low level, and ignore all others. When the unhandled exceptions gets thrown, it will rise up the stack until it gets to the layer that you want to log it at. In my case, it's usually at the business layer where the controling process was started from.

My users (and most other users) don't seem to read the error messages. So I stopped showing them. I just log them.

Agreed. Most of what our users see is "An error has occured, please contact the IS department". There are a few "No data to report", "Please select a printer", and "No such customer" errors that are displayed though. And for time out errors, we display a message that there was a timeout and the process will try again.

Our log file piles up in a hurry (I'm still trying to talk management into letting put 40 hours into a database/web reporting tool for it).

-Rick

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

 

[SqueakinSweep]

The nice thing about this though is that you can catch specific correctable errors at a low level, and ignore all others. When the unhandled exceptions gets thrown, it will rise up the stack until it gets to the layer that you want to log it at. In my case, it's usually at the business layer where the controling process was started from.

Rick ..could you elaborate on this please. Specifically what I am after is to be able to throw errors up the stack and handle them at the relevant layer. I had a quick go at doing something but the JIT debugger still caught everything. I must be missing something obvious.



Sweep
...if it works dont mess with it

 

[ThatRickGuy]

This is all just Psuedo code, so I make no garuntees about it's accurace . It is likely the the DoSubThing1() method will run into a Divid by zero error, which we handle and ignore. Eventually it'll run into an overflow error as the value of Total becomes greater then the maximum value a decimal can be. Since that exception isn't caught in the DoSubThing1() method, it is thrown up to the next level, where there is a generic catch exc as exception that will catch all exceptions. Since the error was unhandled it breaks the process that was running and would be where you report the error to the user/log.

Public Sub DoThing()
  try
    DoSubThing1()
  catch exc as exception
    'If DoSubThing1 throws an exception, it will be caught here

    'Log exc
    'display "An error has occured, contact IS dept" to user
    'clean up the UI as necesary
end sub

Private Sub DoSubThing1()
  dim Total as decimal = 1
  Loop
    try
      dim AddVal as decimal
      AddVal = total/Math.Round(Rnd, 1)
      total += AddVal
    catch exc as DivisionByZeroException
      'A Division by zero exception occured, but we can
      'ignore it and continue on. If any other type of
      'error is throw, we do not handle it here and it 
      'get's thrown to the next layer of the stack
    end try

  Until Total > decimal.MaxValue
end sub

-Rick

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

 

[SqueakinSweep]

Pseudo code it may be, but it explains things perfectly.
Have a star for your efforts.


Sweep
...if it works dont mess with it

 

[zyonman]

We can also create something like this, to handle known possible execption and not handled exeception?
for example:
try
<The Pseudo code>
catch exc as SqlExecption
<The Sql Pseudo Exeception>
catch exc as OleDbExecption
<The OleDb Pseudo Exeception>
catch exc as DivisionByZeroException
<The DivisionByZeroException Pseudo Exeception>
catch exc as Exception
<The General not Handled Pseudo Exeception>
end try

is this a good practice?

 

[Craig0201]

It depends.

I would normally handle those exceptions such as a SQL timeout which can sensible resolved at that level as the component is working correctly with the right input.

I wouldn't normally handle EVERY exception in a routine. Any error due to bad inputs etc should be thrown to the caller to handle.