Hacker News Reader

Comment by vadimberman | Hacker News Reader

Great advice, BUT: apart from the laziness and the poor written communication skills, often the real reason for the vagueness is that these pesky details are simply unavailable to the coders who throw that exception or issue that message. It is buried somewhere deep in the bowels of inner components.

Better error messages start with better architecture.

View on HN

Yes. From the title, I thought the article was about how to actually address that problem.

That said, I wonder if you could invert it. When trying to make a seemingly arbitrary architectural choice, then perhps to break the tie you can ask yourself "if an error occurs, will this allow me to get the right info to the user?"

> When trying to make a seemingly arbitrary architectural choice, then perhps to break the tie you can ask yourself "if an error occurs, will this allow me to get the right info to the user?"

Definitely. That is something I've never heard discussed, and it really should be discussed. User experience is influenced by the inner works of the engine, too.

A similar question arises for logging.

IMHO better error messages start with less architecture. When we try to optimize the code reuse, we obtain a split between the code that detect the error but do not have any cue about the action the user is performing and the caller that will receive a generic error message (string) with no way to do something clever without breaking abstraction.

The higher level can catch the error, and context, and re throw.

Reply on news.ycombinator.com