[crac] RFR: Use special class for exception aggregates [v5]

[Anton Kozlov]

On Wed, 7 Jun 2023 15:42:00 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> When the checkpoint does not fail in JVM code (checking open FDs) but the engine returns non-zero status, the retCode is `JVM_CHECKPOINT_ERROR` but the messages are empty. In this case the exception would look just like CheckpointException without any explanation nor stack trace, and the user would be rather clueless.
>> We could add to this message a hint to check out `dump4.log`, but I am not entirely sure about this as it breaks encapsulation of CR engine (alternative implementations... though we might make CRIU use 'standardized' location) and it might not exist at all, e.g. when the CRIU binary is not present.
>
> Oh, I see. The problem is CHECKPOINT_ERROR serves too many purposes: native descriptor failure, native checkpoint failure, and even native restore failure. I'm fine with this code, but please move this if to translateJVMExceptions with a FIXME comment.

Regarding providing more details, in general, that should be handled by the engine. The criuengine (as the entity controlling the dump4.log name and the path) has a chance to print a few lines from the log. E.g. by calling `system("tail ...")`, although not very pretty, for that will be better than nothing.

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

PR Review Comment: https://git.openjdk.org/crac/pull/64#discussion_r1221827050