Comment by PaulHoule | Hacker News Reader

Comment by PaulHoule | Hacker News Reader

Parent Full thread

We are in the distributed systems age. If systems are composable, operations can fail for reasons that are completely unfathomable to the client. It's not reasonable to have a SharkBitTheOpticFiberCableException and 100,000 other ones that handle every reason why an operation failed.

What the client should know is how an error affects what it is doing, it wants answers to questions like

  * Is it likely this error will recur if I retry immediately? in 1 minute? in 1 day?
  * What is the scope of this error?  Does it affect the entire system?  Does it affect a particular database record?
  * What do I tell the user?
  * What do I tell the system administrator?

Actual improvement in this area won't come from information hiding but it could come out of attaching some kind of ontology to exceptions where exceptions are tagged with information of the above sort, that it is not about having names for them and a hierarchy, but in about having rather arbitrary attributes that help the exception management framework (somewhere high in the call stack!) do the best it can in a bad situation.

While I think this is a good point, a lot of the answers cannot be determined by the generator of the exception. Your SQL library cannot know what the implications of an error are -- is this a minor part of the system for which the error can be logged but mostly ignored, or is it critical? Etc.

People want error handling to vanish so that they can follow the "normal" flow, but in fact error handling is one of the critical things code does.

This is sort of what HTTP codes get at though.

The server doesn't know what you want to do with a 400 but it knows that the problem is with the request for example.

Actually there is somewhat standardized set of SQL error codes and they can be put into a hierarchy like the HTTP codes.

For instance, you can have a SQL error because the syntax of your SQL is wrong. If you're not doing "dynamic SQL" you know this is a programming error (it doesn't matter what input was supplied to the functions.) One common error is "attempted to insert a row with a duplicate key", frequently you want to catch that SQLException and rethrow all the rest.

The ideal SQL library for Java would expose the hierarchy implicit in SQL errors as a class hierarchy.

I had a similar thought a while back [0]. Developing a sane ontology of error types and their implications is a hard problem, but I think it could be done. The subset of errors that is the most frustrating and hard to deal with are ones where, as you point out, the client will have no way to estimate how long a failure mode might persist, at which point you resort to exponential backoff (actually probably an s-curve).

The issue is that sometimes the solution to the issue would require the client to get up and get out a shovel, and go dig somewhere or something. When the abstractions break down that hard there isn't really a way for the developer of the code to handle that unless they somehow stuff a full blown AGI into their program, and even then it would be a stretch.

0. https://github.com/tgbugs/idlib/blob/master/docs/identifiers...

Reply on news.ycombinator.com