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

Question

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.

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.