3 ms·
When you have nested exceptions being caught by other exceptions, how do you determine what level is correct to show the user? Especially when it's a service cl
by llanowarelves 4y ago
When you have nested exceptions being caught by other exceptions, how do you determine what level is correct to show the user? Especially when it's a service class or something that is used by a lot of calling code.
It's implied that it would be the upper top-most exception handlers in that code path but those are gonna be more generic in their messages, and anything more detailed has to be manually wrapped to add useful description (that's not some internal developer exception).
Error codes may be the least bad solution, to fallback on.
- tiborsaas 4y agoIt's hard to give a generic answer to this. I just see way too many bad error messages that could be solved with a little more thought and copywriting skills. Error messages are part of the user experience and they should not be an afterthought. If errors are nested, list them all. Give a generic feedback then, and also provide a technical explanation that would help debugging. Most importantly, we should make the user feel safe and in control as much as possible.
- llanowarelves 4y agoI actually do like "collecting" the errors when possible, and having them return in the API response (for example). Instead of the common pattern where there's just singular "error:" in the top-level json. Works great for things like validation.