Throw exception from transaction work

[Salomon Brys]

Hi there,

is there a way to throw a regular exception (not a RuntimeException) from a transaction's work ?

Bien cordialement,
Salomon BRYS

---

Salomon BRYS | Architecte Logiciel | Chief Geek Officer
Kick Your App
80 Rue des Haies - 75020 - Paris, France
+33 9 72 37 17 24 | +33 6 83 54 55 96 
sal...@kickyourapp.com
Linkedin

[Mat Jaggard]

You can wrap it and unwrap it again.

In the work unit:

throw new RuntimeException(myException);

Outside it:

catch (RuntimeException re)

{

  if (re.getCause() instanceof MyException)

    throw re.getCause();

}

[Jeff Schnitzer]

This is why checked exceptions are a dumb idea, and all the popular post-Java languages eliminate them.

My advice is to never use a checked exception in your code, and immediately convert them to runtime analogs when they do occur.

Jeff

[Salomon Brys]

I soooooooooooooo disagree !

IMHO, checked exceptions are the safest way to enable a method to safely fail by avoiding to poison the return variable (null ref, specific ref, etc.) AND to force the method user to safely verify the error.

Personally, I am found of checked exceptions !

BTW, I did what Mat suggested :)

Bien cordialement,
Salomon BRYS

---

Salomon BRYS | Architecte Logiciel | Chief Geek Officer
Kick Your App
80 Rue des Haies - 75020 - Paris, France
+33 9 72 37 17 24 | +33 6 83 54 55 96 
sal...@kickyourapp.com
Linkedin

[Jeff Schnitzer]

I guess I kicked this off, so I should continue...

That's how they work in theory.  In practice, checked exceptions are incompatible with standard interfaces.  You can't pass checked exceptions through Runnable or List or Iterator or any of the other interfaces we use ever day, so they end up getting wrapped in a RuntimeException.  Even interfaces like Future are a wreck - they throw ExecutionException, which is no better than having RuntimeException but still makes you type a lot of annoying boilerplate.

When was the last time you saw a clean stacktrace, without any wrapping?  I've never seen one in an application of any sophistication.  Each time wrapping happens you get farther and farther from any kind of meaningful ability to handle the error.  ServletException?  Really?

Plus the checked exceptions in the Java standard library are incredibly badly designed.  UnsupportedEncodingException when calling String.getBytes("utf-8")?  Just wow.  "Let's make programmers type a lot of useless crap everywhere!"

C#, Groovy, Scala, Ceylon, Kotlin - pretty much every language post-Java abandoned checked exceptions.  You can even work them out of Java using projectlombok.  As someone else said, "the programmers have voted on this experiment with their feet".

Jeff

[Mat Jaggard]

I have to agree with both of you. I really like the concept of checked exceptions. I.e. this is the list of things that are likely to go wrong here, deal with them please. But as you say Jeff, they don't tend to work out like that in practice.

I'm sad that I can't do the defensive programming that I'd like to sometimes (where I deal with all the possible exceptions in a sensible way, leaving only JVM issues that might crash the program) because runtime exceptions exist, on those occasions I'd rather that runtime exceptions were reserved only for non-java issues. Dealing with checked exceptions the rest of the time is annoying so we're stuck with a half-arsed effort.