Timeline for Sending Exceptions as event arguments
Current License: CC BY-SA 3.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Sep 7, 2015 at 15:27 | comment | added | Elie Steinbock | I didn't mean precise exception information. I meant some kind of notification that things didn't go 100 percent as planned in their language | |
| Sep 7, 2015 at 14:29 | comment | added | Telastyn | @EliezerSteinbock - users should (in general) not see exception information. That sort of info can provide insight to allow security breaches, leak personal information, and is decidedly off-putting to users. Also, they're not internationalized. | |
| Sep 7, 2015 at 14:22 | comment | added | Bart van Ingen Schenau | @EliezerSteinbock: Handling an exception can be that you just inform the user that an operation has encountered a problem. In that sense, the exceptions in your non-critical errors are being handled if you show some kind of feedback to the user. | |
| Sep 7, 2015 at 14:05 | comment | added | Elie Steinbock | So the plan is actually to use a delegate for critical errors, passing in an exception as an argument, and events for non critical errors. The non critical errors will still receive an exception as an argument but will only be used to display info to the user really. Not to handle the exception in any way | |
| Sep 7, 2015 at 13:59 | history | answered | Telastyn | CC BY-SA 3.0 |