[crac] RFR: Use special class for exception aggregates [v4]
Radim Vansa
duke at openjdk.org
Wed Jun 7 08:32:25 UTC 2023
On Tue, 6 Jun 2023 17:03:43 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:
>> `Core` would throw a generic exception when something failed in the native part (`criuengine` returned exit code 1...). A custom implementation of `Context` would throw it when it can't call its children for some reason (but it's not a failure in the Resource itself).
>
> But that does not take away the need for the base CheckpointException to be able aggregate exceptions from Resources, so CheckpointException and Combined are mostly overlaping. Moreover, so we'll need to be able to re-aggregate exceptions of two types. In the current form, Combined and CheckpointException are both fine to be thrown from a user context, and there is no guadance which one to use.
>
> Let's keep it simple and use CheckpointException for aggregations as it was supposed to be. The message constructor should be removed, and every constructor-with-the-message call should be replaced with an exception of different type. Especially since we have examples for this [1].
>
> [1] https://github.com/openjdk/crac/blob/6f403eaf7655f9ce4d10da25082a836d0ad1574c/src/java.base/share/classes/jdk/crac/Core.java#L164
There's nothing that would prevent the message including exception from having suppressed exceptions, it just means that the 'carrier' would not be discarded.
Anyway, if you insist on single type, yes, we can effectively make the CheckpointException = Combined by removing the message, and keeping all info in the suppressed exceptions. Not the best way, IMO, but my main concern is not losing any information by accident.
-------------
PR Review Comment: https://git.openjdk.org/crac/pull/64#discussion_r1221147821
More information about the crac-dev
mailing list