In practice, instead of describing the error, a policy for actionable error messages all too frequently results in something along the lines of
Action failed. Go to https://example.com/foo?code=E123 for more details.
It's "actionable" - there's a place you can go for more information - but there's little or no context, and the web page is frequently vague. You need to dive into logs to find out what goes wrong these days.
I prefer an error message that isn't necessarily actionable, but tells me what the code was trying to do that failed, even if it's very low level.
Error: Disk quota exceeded while trying to write to "D:\scratch\ABCEF.tmp"
This gives me clues. I can recognize a directory I configured, or a filename I'm working with. I know which disk is the problem. Etc.
And of course these two approaches can't be easily melded without transmitting config, detailed failure information including disk free space etc. back to home base.
PS: I use Windows paths here because I noticed a significant degradation in error messages from Microsoft software in the early 2000s, which made it harder to fix problems locally without searching the internet for error codes and randomly trying out fixes from various forums.
I also believe that an industry-wide pull-back from exceptions as an error transmission mechanism resulted in worse error messages. Without runtime polymorphism to encapsulate context from the point of failure, the higher level parts of the app no longer have enough information to even give a descriptive error message, the way a top-level UI exception handler used to.
In practice, instead of describing the error, a policy for actionable error messages all too frequently results in something along the lines of
It's "actionable" - there's a place you can go for more information - but there's little or no context, and the web page is frequently vague. You need to dive into logs to find out what goes wrong these days.I prefer an error message that isn't necessarily actionable, but tells me what the code was trying to do that failed, even if it's very low level.
This gives me clues. I can recognize a directory I configured, or a filename I'm working with. I know which disk is the problem. Etc.And of course these two approaches can't be easily melded without transmitting config, detailed failure information including disk free space etc. back to home base.
PS: I use Windows paths here because I noticed a significant degradation in error messages from Microsoft software in the early 2000s, which made it harder to fix problems locally without searching the internet for error codes and randomly trying out fixes from various forums.
I also believe that an industry-wide pull-back from exceptions as an error transmission mechanism resulted in worse error messages. Without runtime polymorphism to encapsulate context from the point of failure, the higher level parts of the app no longer have enough information to even give a descriptive error message, the way a top-level UI exception handler used to.