다음을 통해 공유

Should Exceptions Carry Error Code Information

  • 아티클

Recently somebody asked me to clarify one of the exception guidelines. They were asking whether it's ok to have a property on exception types that provides access to an error code. I added the following annotation to one of the guidelines:

Do not return error codes. Exceptions are the primary means of reporting errors in frameworks. The chapter overview section describes the benefits of exceptions in detail.

Annotation (Krzysztof Cwalina): It’s ok for exceptions to have a property returning some kind of error code, but I would be very careful about this also. Each exception should carry two main pieces of information: the exception message explaining to the developer what went wrong and how to fix it and the exception type that should be used by handlers to decide what programmatic action to take. If you think you need to have a property on your exception that would return additional error code, think who this code is for. Is it for the developer or for the exception handler? If for the developer, add additional information to the message. If for the handlers, add a new exception type.

Comments

  • Anonymous
    May 27, 2005
    The comment has been removed
  • Anonymous
    June 16, 2005
    Should exception strings be localized?

    If so, how should an english support organizaion handle a support call including a localized error message in japanese?

    In that case, is an error code still a bad idea, since it would allow the error message to be understood by support?

    Or is there a better solution? A Japanese language course perhaps :)
  • Anonymous
    June 06, 2006
    I'm coming in late here; but, I think it's worth noting.  Ideally the granularity of the exception hierarchy should account for all exception scenarios so an added error code is not needed.  In reality it's rare to see an exception hierarchy that accounts for all exception scenarios and code that uses the exception hierarchy to its full potential. Take, for example, most of the System.Web.Services methods.  For the most part the very general (so general as to be meaningless, IMO) WebException is thrown in exceptional (and not-so-exceptional) circumstances.  Based on its type, can anything really be inferred from this?  Of course not.  In order to handle the exception (or more importantly, decide whether it can be handled) the developer must parse the response via WebException.Response.  Usually, it's just a matter of testing the WebException.Response.StatusCode to decide whether the exception should be handled and how to handle it.

    Is it realistic to think every exception scenario can be encapsulated in a distinct exception class?  Or, should this lofty goal simply be viewed as unrealistic and an error code property be added to exception class by habit?  In the case of web response status codes, should a distinct exception class be created for each status code to avoid having the dreaded "error code"?  That would seem very idealistic, if you take into account System.Net.HttpStatusCode supports 273 codes (although not all errors).
  • Anonymous
    August 31, 2006
    When you develop a functionality you notice that all the code throw logicaly "the same kind of" exception. So it is OK to use an error code an reuse the exception type. Whe strictly checking for all possible errors one should assign either a different exception for each throw statement or use a differen error code. The error code is better because it is not of interesst for the exception handler in which throw statement threw the exception but what went wrong. If you has enough discipline you can use resource ids for error codes.
  • Anonymous
    January 19, 2007
    I'm actually a bigger fan of this rule, if only for the readability and maintainability of the code base itself. One of the major problems with frameworks that start with "error codes" is that the list of what these codes means eventually becomes ridiculously long. In a v1.0 application, an error code list may be 20 items, which is certainly manageable, but after many releases, and many upgrades, you may end up with a list that contains hundreds or thousands of different codes which mean all sorts of different things. Even the above-mentioned HttpStatusCode is getting silly, but that's the framework we have to live with.