The Problem
I have always hated being forced to catch an exception, largely because:
- Remember that code you wrote that brings the database backup, adds disk space or memory, grants the correct file privileges as root? Neither do I. If a real problem occurs that is beyond the control of your code, then by definition, you cannot change the outcome. So what's the point of forcing you to handle it?
- Just because something is a problem for you, doesn't mean it's a problem for me. EG, in Java JNI (basically a key/value store), if you look up a value for a given key, but the key does not exist, it throws an exception. It seems the designers of JNI assumed it is the only source of information for a given value. What if it isn't?
- Since there is nothing you can really do in response to an exception, they wind up being re-thrown up to the top, where a web service returns an HTTP 500 code, a GUI displays a "there's a problem we can't fix" dialog to the user.
- If an interface method does not declare any checked exception type, the implementation cannot throw any checked exceptions. But what if the implementation has to make calls that throw checked exceptions?
- Sometimes you're forced to use exception handling as an if/then statement
- Sometimes you need to have nested try/catch blocks, which can be hard to reason about and are invariably not unit tested for each catch statement.
Strategies
If you look at Java code as an example, people use various strategies to try to deal with checked exceptions, such as:
from DZone.com Feed https://ift.tt/3j4nmnm
No comments:
Post a Comment