Closed eighthave closed 4 years ago
Actually I am partially happy with the fact that people need to think about which exceptions to wrap because this makes it explicit what kind of exception is expected by the developer and which is not. Explicitly allowing RuntimeExceptions to be thrown would easily lead to the situation that serious implementation errors ripple through without being noticed. Moreover, allowing such a broad exception type to be thrown is usually considered bad style.
You need to expect RuntimeException at any time, since they are implicitly declared. You cannot assume it will not happen. OtrException on the other hand gets declared but does not make much sense, since it would call upon OtrHost for its own function, e.g. injecting a message into the IM connection, not for OTR-related tasks.
Not relevant anymore.
from @cobratbq: I'm all for simplifying the implementation. Also, something to keep in mind. What's been bothering me is the OtrHost (I think it's called - from the top of my head atm) expects the host instance to throw
OtrException
exceptions. I'd expect to catch (mostly) runtime exceptions and wrap those in anOtrException
in the otr4j method calling upon the host instance, given that you're crossing a boundary there. Just something to keep in mind.