Re: Exception handling best practices

From: David Levine (noSpam12dlevineNNTP2_at_wi.rr.com)
Date: 03/05/05 

Date: Sat, 5 Mar 2005 06:22:03 -0600

Couple of points about:
      catch (SpecialException e) ...

The statement:
    throw new ApplicationException(e.Message);

is usually not a good practice. You should instead use something like this:
    throw new ApplicationException("Some context message that provides
additional meaning to the user.",e);

The original statement would work but usually is not a good practice - all
you are doing is changing the exception type, but you are losing the
original stack trace and are not providing any additional information at
all.

One justification for the original statement is if there is security
sensitive information in the original exception that you do not want exposed
to a higher level component and you wish to hide the data.

An additional reason for transforming the exception type is if the exception
that is caught (SpecialException), is a custom exception that is defined in
an assembly that is not available to modules that have called into your code
(e.g. they are calling across a boundary, either appdomain, machine, etc).
In this case you actually do need to discard the original type and replace
it with a different type. This is because if the calling module does not
have access to the assembly then it will not be able to deserialize the
exception object and that will itself cause another exception to be thrown,
masking the original exception.

In either case I would preserve the original exception message and add
additional context information to aid users in figuring out why it didn't
work.

Another point is that use of the type ApplicationException is being
discouraged as it does not really add much value. There is a ongoing debate
about this and it has not yet been resolved in any camp's favor, but I
personally never use it anymore - I either use a custom exception (rare), or
use the same exception type that was caught (i.e. clone the type), or
sometimes just use Exception.

Couple of points about
 catch (Exception)
 {
   Rollback();
   throw;
 }

Again, this works, but due to a bug in the current version of the runtime it
will lose the original stack information and replace it with a stack that
begins where the throw statement occurs. This is supposed to be fixed in
Whidbey. It also does not add any context information.

I usually prefer to catch-wrap-throw rather then simply rethrow the original
exception. In this case I would probably use something like...

 catch (SpecialException e)
 {
   Rollback();
   throw new Exception("Unable to complete.",e);
 }
catch(Exception ex)
{
  Rollback();
  throw new Exception("I fell down and can't get up.",ex);
}

I always prefer to add information in order to make life as easy as possible
for the users - cryptic error messages should be avoided at all costs.

"cody" <deutronium@gmx.de> wrote in message
news:unSt3lLIFHA.3628@TK2MSFTNGP10.phx.gbl...
> Is this good style? I always have to catch the generic System.Exception
> because our system supports nested transactions that is BeginTransaction
> increases the level, Commit decreases it, rollback sets it to zero, and
> only
> if the level reaches zero the commit/rollback statement is sended to the
> database.
>
> try
> {
> BeginTransaction();
> // stuff
> Commit();
> }
> catch (SpecialException e)
> {
> Rollback();
> throw new ApplicationException(e.Message);
> }
> catch (Exception)
> {
> Rollback();
> throw;
> }
>
>

Relevant Pages

  • Transactions, eval, local and confusion
    ... I have read through the DBI docs and DBD::mysql docs a couple times and ... If the answer to number 1 is no, then presumably 'rollback' throws an ... setting AutoCommit to 0 before setting the RaiseError ... can put it after the RaiseError and let the eval catch its exception as ...
    (perl.dbi.users)
  • [Proposal] using statement enhancements
    ... Mostly always you use the using clause you deal with native ressources, ... exception handlinjg is sooner or later inevitable. ... Rollback(); ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Another question regarding exceptions and loops
    ... In this case I define a transaction as saving a single Contact not the List ... > I think that having separate exceptions for when the list is partially ... > rollback for this kind of thing? ... if there is an exception that is thrown (and I hope you are ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Error when calling SqlTransaction.Rollback method
    ... I've seen this when there was an open data reader on the same connection as ... before rolling back the transaction. ... To get the exception, just debug into your code, or alternatively, ... temporarily remove the rollback code or place it in its own try catch. ...
    (microsoft.public.dotnet.framework.adonet)
  • Re: SharePoint Services Authentication problem (after SharePoint Server removal)
    ... Exception Details: System.UnauthorizedAccessException: Access to the path ... granting access rights to the resource to the ASP.NET request identity. ... System.IO.StreamWriter.CreateFile(String path, Boolean append) +55 ... context) +98 ...
    (microsoft.public.sharepoint.portalserver)