3 ms·
Vexing exceptions
- jwilliams 18y agoThis is good food for thought. When doing service design, I came up with three levels that have some similarities - however - the main focus I had was on if the client code can/should be expected to recover from the exception/error condition. 1. Execution of the method failed. The calling client code can't do anything about it. For example, some system failed. 2. Execution of the method failed, but it's the fault of the calling client. Again, at runtime the client can't be expected to recover. 3. Execution of the method succeeded, but not on the primary path. For example, you asked for some data using and ID that no longer exists (e.g. someone else transacted whilst you were). The calling client code could be expected to take action to recover.
- wayne 18y agoI think many developers believe they must avoid crashes at all costs and add try/catch blocks to catch the Exception base class, which initially sounds like a good idea but usually just hides subtle bugs which are 10x harder to fix later. This article does a great job of classifying exceptions and explaining when you should, and shouldn't, add try/catch blocks.