4 ms·
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 si
by vadimberman 9y ago
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.
- adrianratnapala 9y agoYes. 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?"
- vadimberman 9y ago> 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.
- MaxBarraclough 9y agoA similar question arises for logging.
- reacweb 9y agoIMHO 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.
- martincmartin 9y agoThe higher level can catch the error, and context, and re throw.