Is there a Trealla/Scryer option for the Top-Level

General
1

Was just checking whether Trealla or Scryer have
exception chaining. It seems that they have copied from
each other the top-level. An exception is shown as throw/1:

/* Trealla Prolog */
?- call_cleanup(throw(foo), throw(bar)).
   throw(foo).

/* Scryer Prolog */
?- call_cleanup(throw(foo), throw(bar)).
   throw(foo).

In SWI-Prolog it looks almost like there is exception chaining. I find:

/* SWI-Prolog */
?- call_cleanup(throw(foo), throw(bar)).
ERROR: Unhandled exception: Unknown message: foo
ERROR: Unhandled exception: Unknown message: bar

?- catch(call_cleanup(throw(foo), throw(bar)), E, true).
E = foo.

Is there an option to automatically get the Trealla/Scryer display,
without the need for catch/3?

Edir 16.02.2023
What is exception chaining? You find it in Python:

https://docs.python.org/3/tutorial/errors.html#exception-chaining

I also have it in formerly Jekejeke Prolog, imitating the SWI-Prolog
display, but doing it via exception chaining:

?- call_cleanup(throw(foo), throw(bar)).
Unknown exception: foo
Unknown exception: bar

?- catch(call_cleanup(throw(foo), throw(bar)), E, true).
E = cause(foo, bar).

But the new setup_once_cleanup/3, which adopts the Logtalk idiom,
does something totally different, it overrides the primary exception.
This is incompatible with the usual setup_call_cleanup/3

with or without exception chaining:

?- once_cleanup(throw(foo), throw(bar)).
Unknown exception: bar

?- catch(once_cleanup(throw(foo), throw(bar)), E, true).
E = bar.
2

No. There is only a notion of urgency. For example, an abort overrules a pending error/2 exception. The two messages are from the debugger finding that these exceptions are not caught. The catch/3 call shows only the first exception is preserved (in this case). The exception ordering is described with PL_raise_exception()

I have considered chaining in the past, but it has disadvantages as the exception is unified to the catch/3 2nd argument. If that is instantiated you’ll probably miss the exception. It has been discussed before, I think the current exception handling is rather clumsy IMO.

No. So far I think I prefer trying to turn uncaught exceptions in an as good as possible human readable error report (and trap the debugger if we can).