The JMC RCP application eats a lot of information about exceptions. This happens due to 2 effects:

• The StatusFactory (for reasons I could not understand) takes an exception and instead of just creating a Status object for it, either just extracts the message and stores this in a sub status of a MultiStatus object or it create a sub status object for each line of the exception in a MultiStatus object. The overall effect is having a MultiStatus object without any exception object associated, so the getException() method of the status returns null.
• The BlockingWorkbenchErrorHandler registers a method for creating the detailed area of the problem reporting dialog. This method just tries to show the exception of the status given. But since this is always null, we never see any detailed information.

The only way to get some information about why the problem occurred is to look at the .metadata/.log file. And even there the format is not optimal, since the stack trace is spread over multi stati:

!SUBENTRY 2 org.openjdk.jmc.ui.common 4 0 2022-12-05 16:53:59.986
!MESSAGE java.io.IOException: Test the message
!SUBENTRY 2 org.openjdk.jmc.ui.common 4 0 2022-12-05 16:53:59.986
!MESSAGE     at org.openjdk.jmc.flightrecorder.controlpanel.ui.jobs.DumpRecordingJob.run(DumpRecordingJob.java:91)
!SUBENTRY 2 org.openjdk.jmc.ui.common 4 0 2022-12-05 16:53:59.986
!MESSAGE     at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)

Is there any explanation why JMC doesn't just use a Status object with an exception?