I'd say, yes. I personally dislike the checked exceptions mechanism of
Java, and usually work around it without much sense of guilt -- if my
implementation of some method throws a checked exception I can't
propagate because of an
interface constraint, I usually just throw a new
java.lang.reflect.UndeclaredThrowableException wrapping the original
checked exception.
This works most of the time -- there might be some corner cases where
this is undesirable (i.e. if you'd want to have specific recovery at a
higher level, and the compiler will no longer force you to handle it
so you need to remember it yourself), but as long as your code is
structured so that you don't have much catch blocks but mostly finally
blocks, and a logging catch in the top level invoker of your work unit
(HTTP request, JMS message receipt, UI event, etc.) it's suitable, as
the original exception gets logged and can be inspected.
Attila.
On 2008.11.23., at 22:01, Peter Michaux wrote:
I have a class implementing Scriptable. The "get" method needs to do
some disk work which may throw a checked exception. Scriptable's "get"
cannot throw a checked exception. What is the recommended way to pass
that exception through to the JavaScript? Right now I'm catching the
checked exception and then throwing a RuntimeException (which is not
checked). Is that considered a reasonable approach?
Thanks,
Peter
_______________________________________________
dev-tech-js-engine-rhino mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-js-engine-rhino
