Timeline for answer to Avoiding throw because we are not sure the exceptions will always be caught by Caleth
Current License: CC BY-SA 4.0
Post Revisions
11 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 22, 2024 at 17:03 | comment | added | Ant | I would use absl::StatusOr (or equivalent) rather than std::optional. Not a big difference, but StatusOr also contains the error message if things go wrong. | |
| Apr 21, 2024 at 7:04 | comment | added | Alexander The 1st | I'd add that for point 3 - when something goes so horribly wrong that it does throw outside of the written code, and ends up in case of the 2.)'s crash report - you have to have access to the crash report to know what went wrong, and where. With an Exception thrown example, you can use the Exception's message, stack trace, or even the name of the Exception itself to identify "What went wrong". Really, the biggest issue with stack traces is that they trace up well beyond the most important part relevant to the programmer debugging a thrown exception, because it can't know what's useful. | |
| Apr 20, 2024 at 11:33 | comment | added | Graham | ... For an example of how bad that can go, the UK is currently dealing with a 25-year-long scandal, where failures in Post Office IT systems resulted in over 500 people being wrongly convicted. Many were sent to jail, many were bankrupted, most lost friends or family as a result, some were unable to work again. We're still waiting to see what consequences there will be for the people who carried it out. | |
| Apr 20, 2024 at 11:29 | comment | added | Graham | +1 for the final paragraph, which is the real problem the OP's management haven't understood. Even in a simple desktop application, it's better to lose the last hour's work than to save a corrupted file and lose everything. If this is an application with more significant implications when it goes wrong - a banking app, for example, or stock or forex trading - then there could be legal consequences if the application carries out incorrect operations after an error. | |
| Apr 19, 2024 at 19:52 | comment | added | Schwern | @sayanel Everyone who uses the code needs to understand it, especially the person who has to maintain it 3 (or 30) years in the future. | |
| Apr 19, 2024 at 10:42 | comment | added | Caleth |
@sayanel also optional, although for void functions you'd probably just swap to bool to indicate success, as optional<void> isn't valid
|
|
| Apr 19, 2024 at 10:39 | comment | added | sayanel | Optional look like a good solution indeed in the case of constructor, but what about the general case of any throwing function? | |
| Apr 19, 2024 at 10:28 | history | edited | Caleth | CC BY-SA 4.0 |
added 170 characters in body
|
| Apr 19, 2024 at 10:25 | comment | added | sayanel | Regarding point 1: I expressed it wring and corrected it. Regarding the autosave: you're right, it's not an autosave, it's a crash report. Regarding point 3: I guess the idea is that when you code it you know what you are doing (as opposed to someone who uses your code three years in the future). So it's your responsibility to write code that make valid object. | |
| Apr 19, 2024 at 9:44 | history | edited | Caleth | CC BY-SA 4.0 |
added 231 characters in body
|
| Apr 19, 2024 at 9:35 | history | answered | Caleth | CC BY-SA 4.0 |