[crac] RFR: Fix ordering of invocation on Resources [v3]

[Anton Kozlov]

On Tue, 2 May 2023 06:45:45 GMT, Radim Vansa <duke at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/crac/impl/AbstractContextImpl.java line 59:
>> 
>>> 57:             recordExceptions(e);
>>> 58:         } catch (Exception e) {
>>> 59:             Core.recordException(e);
>> 
>> Why is there is the distinction? I think we should throw all exceptions from the context, rather than publishing them to a central store, otherwise the parent Context (if any), won't be able to do anything about those.
>
> The contexts are supposed to run all resources regardless of whether any failed, therefore there's no point in propagating and re-wrapping the exceptions. We could have a method to check whether this C/R is 'marked for rollback' (has any exceptions), but I don't see why would the parent context decide on the type - because it would get just CheckpointException with a list of other failures from components it does not understand.
> 
> About the distinction: the difference is that if you get a CheckpointException you'd unwrap it, recording only the inner suppressed ones. But I should push that to `recordExceptions` and rather decide based on CheckpointException message than number of suppressions.

> The contexts are supposed to run all resources regardless of whether any failed, therefore there's no point in propagating and re-wrapping the exceptions. ...  I don't see why would the parent context decide on the type - because it would get just CheckpointException with a list of other failures from components it does not understand.

The parent Context may implement an artbitrary handling (for example, unloading a component compleltely if that is throwing an exception). So throwing an exception is something useful.

With that, the new Core.recordException is completely new exception flow, that just opimizes somthing the generic throw scheme. With that, the generic schemes should be something good enough already, we don't need to complicate the interface, the code,.. CheckpointExcepotions are still exceptions, that is, we don't expect them often, there is no need to optimize them.

-------------

PR Review Comment: https://git.openjdk.org/crac/pull/60#discussion_r1182328171