> Marshalling is known to be type unsafe, of course, so that's "not a
> problem" although it would be nice to have type-safe marshalling.

I don't agree here, there really *is* a problem with marshalling
exceptions, independently from type safety: it doesn't work. This problem
has already been mentionned on the list (and in the bug tracker), which is
why I didn't describe it in detail. However, it would be nice to have a
word from the caml team about it.

Let's suppose we have two processes running the exact same compiled program.
- Process A marshalls an exception (Ex "arg")
- Process A transmits the resulting string to process B
- Process B unmarshalls the string, and makes sure to type it as an
exception. Since we have the same compiled program, exception Ex is defined
in the same way in A and B.
- On process B, the exception *seems* right, and you can test equality.
However, if you try to pattern-match against it, the process just hangs.

As I understand it, the constructor Ex of the variant type exn is
represented by a pointer in (Ex "arg"), and this pointer is kept as-is by
the marshaller which doesn't understand the particular structure of
exceptions.

The (awfully ugly ;-)) workaround I used (I *really* needed to marshal
exceptions, you see...) is to extract the constructor (as a string) and the
parameters from the exception, using Obj, marshal the couple and deal with
it on the receiving hand.

> However, what happens with dynamically loaded bytecode that declares
> new exceptions? Perhaps there is some unsoundness there... :-)

Yes, that could be worth looking into, but I don't actually think it makes
the problem worse since the structure of exceptions is already dynamic.

Thanks for the pointers :-)
Louis