Timeline for The best way to handle exceptions?
Current License: CC BY-SA 4.0
8 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 15, 2024 at 20:23 | comment | added | Cort Ammon | You do need more information, such as "If A FileNotFoundException is thrown, this function will have been nullimpotent" Then you know there were no tricky side effects to worrya bout. | |
| Nov 15, 2024 at 20:22 | comment | added | Cort Ammon | Fundamentally you need to know enough about what went wrong to understand the side effects of what did (irreversibly) occur. If one just intends to terminate the equation or just keep going and pray that nothing is broken, then you really don't need any information about the exception at all. If one wants to do more than that, one typically needs to know something about the exception that happened. Type information is the first layer of that, but just the first layer. | |
| Nov 15, 2024 at 8:23 | comment | added | Phill W. | We'll agree to disagree. IMHO, you're under-valuing SEH and potentially breaking Separation of Concerns as well, by over-complicating each method with "fallback" code that should be elsewhere (and context-dependent). At least you'll never need to create any of your own Exception [sub-]classes, since you only ever report a "failure". | |
| Nov 14, 2024 at 10:55 | comment | added | Ralf Kleberhoff | @PhillW. We seem to advocate different architectures regarding the role of failures and exceptions. Your architecture is that the exception not only communicates that the method failed and why it failed, but also the information what can be done by an automat to mitigate the failure (e.g. retry). In my architecture a method that can give hints how to make it succeed should take these actions itself before throwing. That's not always possible, but my preferred way. | |
| Nov 14, 2024 at 9:50 | comment | added | Phill W. | "recovery strategy" = "Handling". "Can I ... devise a viable recovery strategy ..." Yes. The called method could not do what was needed. Now the calling method can try /something else/! "Do ... I know enough about the ... method ..." You don't /need/ to. What matters is what's you can "usefully" do with the Exception. "... that I can base that strategy on the exception type?" That's exactly what you're /supposed/ to do. The Exception should give you, the Handler, sufficient information that you can. If it doesn't, you can't handle it, so don't catch it. | |
| Nov 14, 2024 at 8:52 | comment | added | Ralf Kleberhoff | @PhillW. (I know that this has the potential for heated discussions). If a method fails, then I typically fail as well. I can either let the exception bubble up (my preferred way), or wrap it into some other type. I should catch an exception (without re-throw) only if I can turn the method's failure into my success by some "recovery strategy". Can I (as an outsider to the method) devise a viable recovery strategy, better than the method itself can do? Do (and should) I know enough about the inner workings of the method that I can base that strategy on the exception type? | |
| Nov 14, 2024 at 8:28 | comment | added | Phill W. | We MUST pay attention to the Type of Exception! The most important part of Structured Exception Handling is the Handling part, for which you need to know /what/ went wrong and, ideally, /why/. Agreed, your code has no need for "analyzing the failure reason". It's already been handed that because it caught a specific Type of Exception. Then, it just has to do something "useful" with it. | |
| Nov 14, 2024 at 8:18 | history | answered | Ralf Kleberhoff | CC BY-SA 4.0 |