Timeline for Why do many exception messages not contain useful details?
Current License: CC BY-SA 3.0
8 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 18, 2015 at 14:11 | comment | added | Peter Mortensen | Yet, Jon Skeet wrote: "System.InvalidCastException would be so much more useful if the error message included the requested target type and actual type." | |
| Apr 13, 2015 at 19:56 | comment | added | user22815 | @MartinBa I cannot find a link to this but at a previous employer we had to scrub SQLException strings coming back from SQL Server's JDBC driver. If the login info was incorrect, it would have the plaintext username and password embedded in the exception text. Despite the log files not being user-accessible, it was still a breach of financial regulations and we had to scrub the data while keeping the exception. It had valuable information for developers to figure out why a connection failed. | |
| Apr 13, 2015 at 19:38 | comment | added | Martin Ba | Thanks for sharing that insight. Personally, I don't agree and think the security argument is a complete fallacy, but it may be a rationale. | |
| Apr 13, 2015 at 16:37 | comment | added | user22815 | @gbjbaanb who says we need to show the full stack trace to the user? | |
| Apr 13, 2015 at 16:33 | comment | added | gbjbaanb | @Snowman I hardly think security is a consideration when a full stack trace is available, and index number is not. Sure I understand an attacker probing for buffer overflows, but many exceptions leave out quite safe data too (eg which Oracle table wasn't found) | |
| Apr 13, 2015 at 16:00 | comment | added | user22815 | @BenAaronson the identity/class of the exception tells us the type of error. My point is the details might be omitted (i.e. what specific value caused the error) for security. That value might be traceable back to the user input, revealing information to an attacker. | |
| Apr 13, 2015 at 15:58 | comment | added | Ben Aaronson | 1. Based on this criteria it seems relatively arbitrary what information is ("Index out of range", stack trace) and isn't (value of index) shown. 2. Debugging can potentially be a lot faster and easier when relevant dynamic values are known. For example it would often immediately tell you whether the problem is garbage input to the piece of code that failed, or that code failing to correctly deal with good input | |
| Apr 13, 2015 at 15:41 | history | answered | user22815 | CC BY-SA 3.0 |