3 ms·

The error here is not that they are wrapping the exception necessarily. It is that they re-threw it as an unchecked exception. I strongly believe the only good

by zaphar 4y ago

The error here is not that they are wrapping the exception necessarily. It is that they re-threw it as an unchecked exception. I strongly believe the only good use of unchecked exceptions is if the code should do the closest reasonable thing to crash safely. Everything should be clearly communicated to the callers so they can make good decisions about what to handle here and what to pass up the chain. If the complaint is that you then have too many different unchecked exceptions perhaps the error domain has been improperly modeled and you are getting a clue that the system is poorly designed.

Quekid5 4y ago
> The error here is not that they are wrapping the exception necessarily. It is that they re-threw it as an unchecked exception. You often don't have a choice. Think of generic interfaces -- for example the humble apply method on https://docs.oracle.com/javase/8/docs/api/java/util/function/Function.html https://docs.oracle.com/javase/8/docs/api/java/util/function... . If you have a Function which needs to do some interruptible work you cannot throw InterruptedException -- you must wrap it. This is a fundamental design flaw in Java's exception system and cannot be handwaved away just by saying that Function is badly designed. This problem is pervasive. The ultimate problem here is one of variance -- throws clauses have the opposite variance rules from method implementations: Subclasses (whether of interfaces or classes) frequently need to more than could be foreseen by the implementor of the interface, so they need to be able to throw "more things", but checked exception clauses explicitly disallow widening the set of thrown exceptions in subclasses (for obvious reasons -- since a FooImpl can be used a runtime where a Foo is expected). This is a fundamental flaw that was overlooked in the checked exceptions design and there's no fixing it now.

by zaphar 4y ago

Quekid5 4y ago

> The error here is not that they are wrapping the exception necessarily. It is that they re-threw it as an unchecked exception. You often don't have a choice. Think of generic interfaces -- for example the humble apply method on https://docs.oracle.com/javase/8/docs/api/java/util/function/Function.html https://docs.oracle.com/javase/8/docs/api/java/util/function... . If you have a Function which needs to do some interruptible work you cannot throw InterruptedException -- you must wrap it. This is a fundamental design flaw in Java's exception system and cannot be handwaved away just by saying that Function is badly designed. This problem is pervasive. The ultimate problem here is one of variance -- throws clauses have the opposite variance rules from method implementations: Subclasses (whether of interfaces or classes) frequently need to more than could be foreseen by the implementor of the interface, so they need to be able to throw "more things", but checked exception clauses explicitly disallow widening the set of thrown exceptions in subclasses (for obvious reasons -- since a FooImpl can be used a runtime where a Foo is expected). This is a fundamental flaw that was overlooked in the checked exceptions design and there's no fixing it now.