On 3.5.12 13:43, Julian Reschke wrote:
On 2012-05-03 14:26, Thomas Mueller wrote:
Hi,
I wouldn't want to catch RuntimeException. I'd prefer if oak-core would
only throw OakException (extends RuntimeException), as suggested by
Michael Dürig.
+1
I also think it would be good if these Oak exceptions could carry
sufficient information to generate a JCR exception.
+1
The mappings that have been suggested by Michael and above would help,
but we'd lose correctness in the call stack, right?
Do you mean instead of one simple stack trace you would get two (the
original one as "Caused by:")? I think that's OK. If it's really a
problem
we could still use Exception.setStackTrace(..), but I don't think that's
necessary.
If the OakException wraps a RepositoryException, we extract that one and
rethrow it, it will come with an incorrect stack trace, no? So it seems
we need to re-wrap.
Just for the fun of it: instead of wrapping we could also trick the
compiler into thinking we throw unchecked exceptions where in reality we
throw checked exceptions:
public static void throwUnchecked(Throwable e) {
OakException.<RuntimeException>throwIt(e);
}
@SuppressWarnings("unchecked")
private static <E extends Throwable> void throwIt(Throwable e) throws E {
throw (E)e;
}
now
public void foo() {
throwUnchecked(new NamespaceException("foo"));
}
throws a NamespaceException without the compiler complaining ;-)
Credits to Alexey [1]
Michael
[1]
http://blog.ragozin.info/2011/10/java-how-to-throw-undeclared-checked.html
It seems we're converging on
- OakException extends RuntimeException
- OakExpception can carry RepositoryException
Should we start with that, and see how this works? (Open a issue for it?)
Best regards, Julian
