Freigeben über

Exceptions vs. Error codes with Services

  • Artikel

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.

Comments

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

  • Anonymous
    July 10, 2007
    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.

  • Anonymous
    July 10, 2007
    @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

  • Anonymous
    July 11, 2007
    The comment has been removed

  • Anonymous
    July 12, 2007
    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.

  • Anonymous
    July 17, 2007
    You've been kicked (a good thing) - Trackback from DotNetKicks.com

  • Anonymous
    July 26, 2007
    The comment has been removed