Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jta-dev] Handling java.lang.Error within the CDI interceptor

Hi Tom,

Thanks for the response. The keypoint here is that by Java spec the Error is considered as an unchecked exception. That way the Synchronization talks about how to handle runtime and errors.

Java Language Specification, version 11, chapter 11.1.1:

The unchecked exception classes are the run-time exception classes and the error classes.

The checked exception classes are all exception classes other than the unchecked exception classes. That is, the checked exception classes are Throwable and all its subclasses other than RuntimeException and its subclasses and Error and its subclasses.

With that the java.lang.Error is an unchecked exception while the Throwable is a checked exception. At the same time, JLS also says a little bit opposite which makes handling an exception implementing the Throwable a bit gray area.

Exception is the superclass of all the exceptions from which ordinary programs may wish to recover.

But I'm asking about Error in particular. I would like to suggest aligning the wording to change all occurrences of RuntimeException to the term "unchecked exception" in the Jakarta Transactions specification, for consistency and for the meaning.

I will prepare a PR with such a change and you can review and consider if it's ok.

Thank you!


On Wed, Apr 21, 2021 at 1:36 PM Tom Jenkinson <tom.jenkinson@xxxxxxxxxx> wrote:
Hi Ondra,

My understanding is runtime exceptions are unchecked exception and so in that sense are they effectively synonyms here.

I think the key thing is that neither @Transactional or the Synchronization notes explicitly state how to handle java.lang.Errors. I don't think the Jakarta EE platform itself does either. Looking at then I don't personally think that it's expected that the application deal with the error. I can't see reference to java.lang.Error in the platform specification either:

So my assumption is it is intentional to not define how to deal with the abnormal condition as defined in the java.lang.Error javadoc in Jakarta EE project. That could be a useful topic for wider discussion in the Jakarta EE community if it's something the platform want constituent projects to deal with.

BTW - if I misunderstood a bit the question and you are looking to align the wording of RuntimeException and unchecked exception in the Jakarta Transactions specification for consistency in how that concept is referred to (and not asking about java.lang.Error) then I would be happy to review a PR aligning that wording.

Thanks for the question,

On Mon, 19 Apr 2021 at 12:29, Ondra Chaloupka <ochaloup@xxxxxxxxxx> wrote:

I'm Ondra Chaloupka, a member of the Narayana team. Recently we've got a question from a user about handling of java.lang.Error thrown in a method of a CDI bean. The question is if a transaction started by the CDI @Transactional  interceptor should be marked for rollback.

As I was reading the current JTA specification it's not clear (at least to me). The spec says

By default checked exceptions do not result in the transactional interceptor marking the transaction for rollback and instances of RuntimeException and its subclasses do.

There is not said what to do with other un-checked exceptions. There is mentioned explicitly only the RuntimeTransaction here.
On the other hand, the text about Synchronization says that

An unchecked exception thrown by a registered Synchronization object causes the transaction to be aborted.

Should not be changed the text about CDI @Transactional interceptor in the same way - i.e. from explicit RuntimeException to term 'unchecked exception'?

Thank you,
jta-dev mailing list
To unsubscribe from this list, visit
jta-dev mailing list
To unsubscribe from this list, visit

Back to the top