Browse thread
Re: [Caml-list] Bugs with pattern-matching and exceptions
- Louis Gesbert
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: | 2006-03-01 (23:07) |
From: | Louis Gesbert <louis.gesbert@l...> |
Subject: | Re: [Caml-list] Bugs with pattern-matching and exceptions |
> 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