Ron Jacobs

Windows Workflow Foundation

Exceptions vs. Error codes with Services

Exceptions vs. Error codes with Services

Rate This
  • Comments 7

Here is an interesting question from the MSDN ArchitectureGeneral forum that I decided to answer.

To throw exceptions or use error codes – that is thequestion…

Since God has not handed down any commandments related tothis I think this is a question of principles. 

We want to choose the option that is

1.      Easy to understand, code and use

2.      Consistent with the intent of the language/technologydesigners and common practice

Let's start with the second principle.

According to the .NET FrameworkClass Library Design Guidelines

“Exceptions are the standardmechanism for reporting errors. Applications and libraries should not usereturn codes to communicate errors. The use of exceptions adds to a consistentframework design and allows error reporting from members, such as constructors,that cannot have a return type. Exceptions also allow programs to handle theerror or terminate as appropriate. The default behavior is to terminate anapplication if it does not handle a thrown exception.”

So in this case you have to come down on the side ofexceptions.

As for principle #1 Ease of use…

Developers must always account for exceptions.  They do notalways have to account for error codes.  Many times in my old COM programmingdays bugs were introduced when developers ignored bad HRESULTS.  (Yes baddevelopers can ignore exceptions as well but the error is more obvious).

WCF provides a mechanism for declaring the kinds of faultsyour application can throw with a fault contract.  Yes, SOAP does not useexceptions per se.  This is because exceptions are a language specificconstruct.  However, most SOAP implementations convert faults into exceptionsfor you.

My vote… Go with exceptions, use faultcontracts… this is goodness.

 

  • Do you have more information on faultcontracts? I have never heard of this before and would like more information on the subject.

  • There was some discussion a while back about the performance implications of throwing exceptions inside asp.net.  This probably doesn't apply to that many real projects though (just the big ones).

    http://msdn2.microsoft.com/en-us/library/ms998549.aspx#scalenetchapt06_topic22

    I always try to remember the rule of thumb about not using exceptions to control logic.  Only use them for "exceptional" situations. lol

    Oh, and I shudder everytime I see code the swallows all exceptions.

  • @Ian Qvist :

    Fault Contract are WCF's way of comunicating exception across distributed systems (ie server to client).

    http://msdn2.microsoft.com/en-us/library/ms752208.aspx

  • I agree with you.  Generally speaking, I prefer to go with explicit exceptions rather than error codes.  An explicit exception and the corresponding message provides a lot more clarity than a vague error number.

    Just my two cents.

  • Exceptions are the accepted best practices for handling "errors" in a sequential program - ie, single-threaded code running in a single process/app domain.

    Once we move to a distributed world, one that is not necessarily sequential, with different things running at different times and/or occurring in parallel, it is less clear the advantages exceptions have.

    When we consider the two criteria:

    "

    1. Easy to understand, code and use

    2. Consistent with the intent of the language/technologydesigners and common practice

    "

    The problems occur at a more general level. Distributed and parallel processing are inherently difficult to understand. Language and technology designers admit to addressing these domains inadequetly.

    If you design and use services as if they were just objects running in your own process, then absolutely use exceptions. However, be aware that that style of design has been long ago proved to lead to performance and stability problems unsolvable without major redesign efforts.

    My post on <a href="http://udidahan.weblogs.us/2007/03/23/errors-exceptions-and-asynchronous-web-services/">using exceptions with asynchronous web services</a> shows the nitty-gritty details. Check it out.

  • You've been kicked (a good thing) - Trackback from DotNetKicks.com

  • There's one other thing about the quote from the framework design guidelines that I can't quite seem to forget.

    Data flows and processes which cross service boundaries are different from the objects and components within that boundary.  We know that distributing objects is bad (if you believe Martin Fowler), but we know that objects inside our application is goodness.

    Things which work well within an application/service/component may not translate well to cross-service interactions.

    How this translates to exceptions and soapfaults is up for debate, but it's something to think about.

Page 1 of 1 (7 items)