3 ms·

That's not really a respectful practice. Error messages should be clear and actionable. Users don't care if you consider an error soft or hard.

madeofpalk 4y ago
I think the point is that the higher up you fail, the harder it is to identify why you errored in order to give the user clear and actionable feedback.
- tiborsaas 4y ago
  That's possibly indicating a bad UI / information architecture if you are unable to tell that.
  - 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 ago
      It'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 ago
        I 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.
P5fRxh5kUvp2th 4y ago
Fail Fast means your logging infrastructure is going to report to you more quickly to get the problem fixed. As opposed to 6 months down the road when someone finally notices an uptick in complaints by customers and now the potential problem sites is literally the entire software stack. fail fast is how stable software is made, the question is whether or not you think customers appreciate stable software.

madeofpalk 4y ago

I think the point is that the higher up you fail, the harder it is to identify why you errored in order to give the user clear and actionable feedback.

tiborsaas 4y ago
That's possibly indicating a bad UI / information architecture if you are unable to tell that.
- 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 ago
    It'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 ago
      I 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.

P5fRxh5kUvp2th 4y ago

Fail Fast means your logging infrastructure is going to report to you more quickly to get the problem fixed. As opposed to 6 months down the road when someone finally notices an uptick in complaints by customers and now the potential problem sites is literally the entire software stack. fail fast is how stable software is made, the question is whether or not you think customers appreciate stable software.