"onthrow" and "onuncaught" are debug agent arguments used to trigger deferring debug agent initialization and debugger attachment until after an exception is thrown. "onthrow" will defer until the specified exception is thrown, and "onuncaught" will defer until any uncaught exception is thrown. These arguments are not part of any specification. They are debug agent implementation features and are documented here:

https://docs.oracle.com/en/java/javase/17/docs/specs/jpda/conninv.html#oracle-vm-invocation-options

The issue is that they rely on some undocumented JDWP and JDI features, or at the very least are making some assumptions about what is being specified.

After debug agent initialization and debugger attachment, these options result in sending an ExceptionEvent which has a requestID of 0. The JDWP spec says this indicates that it was an automatically generated event. The JDWP spec also says:

"The VM Start Event and VM Death Event are automatically generated events. This means they do not need to be requested using the EventRequest.Set command."

The debugger will get this ExceptionEvent even if no ExceptionEventRequest was made for it. So there is an inconsistency here since the ExceptionEvent is not really "automatically generated" (there was actually an exception thrown), and there's nothing in the spec to indicate that an ExceptionEvent might be delivered with a requestID of 0.

On the JDI side, the requestID of 0 results in event.request() returning null. The spec for Event.request() does say:

"Some events (eg. VMDeathEvent) may not have a corresponding request and thus will return null."

So JDI doesn't really say anything about "automatically generated events", but only mentions that some events may not have an EventRequest associated with them. [Edit: the JDI spec also mentions that VMDisconnectEvent has no corresponding EventRequest.]

From the debugger point of view, the main thing that they need to be aware of is that they can get an ExceptionEvent with no EventRequest associated with it. I'm not so sure there is anything in the JDI spec that precludes this, but it might be worth pointing out in an implementation note of some sort.

In the JDWP spec, it would be good to clean up the language around "automatically generated events", and also when/why requestID is set to 0. It should include mention of this special ExceptionEvent.