Why is nesting or piggybacking errors within errors bad in general?

To me it seems bad intuitively, but I'm suspicious in that I cannot adequately articulate why it is bad. This may be because it is not in general bad and that it is only bad in specific instances. Why is it detrimental to design error/exception handling in such a way.

The specific instance is that of a REST service. There is a desire by some to use http errors (specifically the 500 response) as a way to indicate any problem with specific instances of a resource. An example of an instance resource in this case would be:

  http://server/ticket/80 # instance
  http://server/ticket # not an instance

So this is the behavior that is being proposed.

  • If ticket 80 does not exist return a http response code of 500. Within the body of the error return the "real" error as an additional error code and description.
  • If the ticket resource doesn't exist return a response code of 404.
  • Error 500 is "the Web server encountered an unexpected condition that prevented it from fulfilling the request by the client." In other words, an internal error occurred. Your first bullet seems more properly a 404. http://server/ticket doesn't seem like a well-formed URL to me, since the information needed to fulfill the request is missing; it should also return a 404. Oct 1, 2012 at 19:15
  • @RobertHarvey: I agree, but is there a general reason that applies even with other cases like a SOAP call, RPC, etc?
    – snakehiss
    Oct 1, 2012 at 19:27
  • Error 500 seems reasonable, if the resource actually exists and some other error has occurred. If the resource (in your example Ticket 80) doesn't exist, it's still a 404, and that's unambiguously clear to anyone calling your service. In other words, it's the behavior any caller would reasonably expect. Oct 1, 2012 at 19:37
  • For http://server/ticket, 404 seems like a reasonable error code. 410 ("Gone") might also make sense, because unlike 404 it indicates that the resource is not going to be back later.
    – sleske
    Oct 2, 2012 at 3:39

1 Answer 1


The problem with piggy-backing errors is that when it occurs, you don't know which of the potential errors is the real problem.

In your case, returning an http error code of 500 could mean:

  • the ticket doesn't exist
  • there's a problem accessing ticket #80
  • there's a problem in recalling and populating ticket #80 with information

In general, a piggy-back technique is lazy. Lazy can be good, but lazy can also be really bad. In this case, I'm voting for the latter.

This one is lazy bad because when (not if) that error occurs, you'll have to do double or triple the amount of work in figuring out what really went wrong. On a small enough system, that might be tolerable. In a high volume or marginally stable environment, the lazy approach is a good recipe for a serious headache.

The right approach is to code up an error page that indicates

  • something went wrong
  • the system proactively detected something went wrong (which is not the same as the first item)
  • diagnostic information has been sent to a sysad account or present the diagnostic information to be provided in the trouble call.

If you were really hard up for development time then at least use a much lesser used http error code so you can bypass some of the which-error-was-it troubleshooting.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.