How do you use Try statements? 1

[meckeard]

I am starting to get into error trapping with the Try statement and was wondering how others are using it.

More specifically, do you use one on every part of your code that could throw an error or just one for the entire process in the page?

Example, let's say you need to execute 2 functions in your code:

objCart.UpdateCart()
objCart.DisplayCart()

Would you wrap this within 1 try statement or 2? I would think 2 so you could get a better handle on the actual error. If you use 1, the error could happen in either place and you would have trouble finding it.

Thanks,
Mark

 

[link9]

Actually, one would do it because what should be happening is that in the various methods, you should have other try/catch constructs wherever you expect that there MIGHT be an error.

In those cases, you will catch the exception and return something meaningful to the caller. For example, in your .UpdateCart() method:

try
{
 //some code here
}
catch(SqlException exc)
{
   throw new ApplicationException("Update cart had a SQL error!", exc);
}
catch(DivideByZeroException exc)
{
   throw new ApplicationException("Update cart tried to divide by zero!", exc);
}

So you see, you've caught it, added some meaningful information to it, and then bubbled it on up the chain. It will then be caught by the main try/catch in the caller, where you can do something with it.

System exceptions will just be thrown. Again, caught higher up the chain.

Notice that I included the original exception with my new one. That's very important also.

Take it another step. At a very basic level, exceptions are classed into Application Exceptions and System Exceptions. Application exceptions are exceptions that your application will throw, and System exceptions are thrown by the framework. Whenever you expect that there might be an error, you should catch those errors, new up an application exception (including the original exception) and then throw it.

In this way, you can construct the main try/catch like this:

try
{
   objCart.UpdateCart();
   objCart.DisplayCart();
}//try
catch(ApplicationException exc)
{
  lblException.Text = "We had an application exception.  Details<br>: " + exc.Message;
}//catch
catch(Exception exc)
{
  lblException.Text = "We had a System Exception!  Man, we didn't expect that!  Details<br>: " + exc.Message;
}//catch

I should also say that you can even create your own exceptions. MissingCustomerException, for example. You can derive a class from SystemException, add your own information, call it what you will, and then trap those separately, as well. For example, if a MissingCustomerException is thrown, maybe you'll redirect your visitor to a page where they can sign up for a new account.

So as you can see, with structured exception handling, the possibilities are limitless as to how you can handle your errors. It's very elegant, and if you spend some time setting up an error handling framework, you'll really have some meaningful information to help you not only track down any bugs that might exist in your software, but give your users a much richer experience.

Be sure to check out Google on this subject for lots and lots of examples. I've really only scratched the surface here.


paul

The answer to getting answered -- faq855-2992

 

[jen89]

Paul, thanks for the great info! The bit about throwing it up to the caller was particularly helpful to me, as I usually catch things but the messages get lost before they bubble up to the top.

The one question I had was about the divide by zero exception. Isn't it more correct to do a check for a divide by zero scenario before performing the division? I thought that using catch to trap preventable errors could be detrimental to performance, especially if it might take place in a loop. If the error needs to be thrown, is it possible to detect a divide by zero scenario using an if/then statement and still throw the error?

 

[link9]

More correct" ?? I think that's subjective.

Better performance? Yes, probably. But remember that the fastest solution isn't always the best solution.

Arguments could be made from either side, but the point here is that I was using that as a demonstration to show that you can catch different types of exceptions and handle them differently if you want.

-paul

The answer to getting answered -- faq855-2992

 

[cappmgr]

Paul: I believe you want to derive custom exceptions from ApplicationException not SystemException.
Reading up on InnerExeption is also very helpfull if you are losing information. Rethrowing is needed but thought needs to be put into it, I believe rethrowing is expensive.
Marty

 

[meckeard]

Paul,

That's good stuff. Thanks for the info.

Mark

 

[link9]

Marty, you're correct. That was a typo.

Custom Exceptions should be derived from ApplicationException, not a system exception. Thanks for the correction.

-p

The answer to getting answered -- faq855-2992