Timeline for Exceptions: Why throw early? Why catch late?
Current License: CC BY-SA 3.0
16 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Dec 30, 2019 at 21:22 | comment | added | gnasher729 | Your code checking whether integer division is allowed is incorrect. Division by zero is not the only problem. MININT / -1 is the other problem. | |
| May 23, 2017 at 11:33 | history | edited | CommunityBot | replaced http://stackoverflow.com/ with https://stackoverflow.com/ | |
| Jul 24, 2014 at 10:22 | comment | added | Daniel Dinnyes | @supercat About your suggestion on configurable error handlers: exactly! In my last example the error handling logic is hard-coded, calling the static doMyBusiness method. This was for the sake of brevity, and it is perfectly possible to make it more dynamic. Such a Handler class would be instantiated with some input/output resources, and have a handle method which receives a class implementing a ReusableBusinessLogicInterface. You could then combine/configure to use different handler, resource, and business logic implementations in the wiring layer somewhere above them. | |
| Jul 24, 2014 at 10:02 | comment | added | Daniel Dinnyes | @supercat I understand what you are saying. I would say a concrete resource implementation is responsible to know the exceptions it can throw. It doesn't have to specify everything (there is so called undefined behavior), but it must ensure there is no ambiguity. Also, unchecked run-time exceptions are to be documented. If it contradicts the documentation, then it's a bug. If the caller code is to be expected to do anything sensible about an exception, the bare minimum is that the resource wraps them in some UnrecoverableInternalException, similar to an HTTP 500 error code. | |
| Jun 25, 2014 at 15:16 | comment | added | supercat | ...may be icky, but it would seem better than assuming that any FailingInputResource exception will be a result of an operation with in1. Actually, I think in many cases the right approach would be to have the wiring layer pass an exception-handling object, and have the business layer include a catch which then invokes that object's handleException method. That method could rethrow, or supply default data, or put up an "Abort/Retry/Fail" prompt and let the operator decide what to do, etc. depending upon what the application required. | |
| Jun 25, 2014 at 15:13 | comment | added | supercat | You are correct that the code supplying the interface will know more about what can go wrong than the code that uses the interface, but suppose a method uses two resources of the same interface type and failures need to be handled differently? Or if one of those resources internally, as an implementation detail not known to its creator, uses other nested resources of the same type? Having the business layer throw WrappedFirstResourceException or WrappedSecondResourceException and requiring the "wiring" layer to look inside that exception to see the root cause of the problem... | |
| Jun 25, 2014 at 11:18 | history | edited | Daniel Dinnyes | CC BY-SA 3.0 | made doDivide() method examples more stateful by doing reading in method body to reflect the intentions of the examples better. |
| Mar 7, 2014 at 13:05 | history | edited | Daniel Dinnyes | CC BY-SA 3.0 | nah, i was lying... still more edits ;) |
| Mar 7, 2014 at 12:26 | history | edited | Daniel Dinnyes | CC BY-SA 3.0 | some major content changes... this is the final version, no more edits :) |
| Mar 7, 2014 at 11:05 | history | edited | Daniel Dinnyes | CC BY-SA 3.0 | extended last paragraph a bit, also some more stylistic fixes |
| Mar 7, 2014 at 10:28 | history | edited | Daniel Dinnyes | CC BY-SA 3.0 | minor changes in style here-n-there |
| Mar 7, 2014 at 10:17 | history | edited | Daniel Dinnyes | CC BY-SA 3.0 | minor change in sentence |
| Mar 6, 2014 at 20:37 | history | edited | Daniel Dinnyes | CC BY-SA 3.0 | some more stylistic changes |
| Mar 6, 2014 at 16:32 | history | edited | Daniel Dinnyes | CC BY-SA 3.0 | some stylistic changes |
| Mar 6, 2014 at 15:58 | history | edited | Daniel Dinnyes | CC BY-SA 3.0 | it's not unfortunately... |
| Mar 6, 2014 at 15:50 | history | answered | Daniel Dinnyes | CC BY-SA 3.0 |