+972 52-548-6969
Make the error useful, and save the support call
time to read 1 min | 119 words
Another code review comment, this time this is an error message being raised:
The comment I made here is that this error message lacks a very important detail. How do I fix this? In this case, the maximum number of connections is controlled by a configuration setting, so telling that to the user as well as what is the actual configuration entry to use is paramount.
If we give them all the information, we save the support call that would follow. If the user don’t read the error message, the support engineer likely would, and be able to close the ticket within moment.
Comments
Going on that direction, can you imagine how world would look like if c# NullReferenceException contained variable name?
React does a very good job of conveying information like this: in the dev builds, when there's an error, there's almost always a phrase like "did you forget to do <something we expect>"
I agree with this completely and have started doing this as practice as well in error messages.
Rufik,
In almost all cases, just the line number is sufficient, but yeah, that can be a huge benefit. I remember looking at the same error in C++ and C# two decades ago, and NRE vs. Access Violation @ 0x382381 made me switch to C#
Rufik, the world would look much better and easier. It'S a massive problem that our error reporting infrastructure is so bad - yes we do have exceptions, but they are not realle up to the task in a lot of cases. E.g. in case a NRE with a variable name would help but does not explain why its null. Would be so much better when we would be able do understand the why easier.
Comment preview