New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
exceptions lose identity after marshalling #4978
Comments
Comment author: gerd I've found a workaround in my code. So far I see it is difficult to fix this problem in Marshal: exceptions do not have a tag of their own, and cannot even recognized by the marshaller. Maybe just mention this problem in the documentation? |
Comment author: @damiendoligez Definitely mention the problem in the docs. |
Comment author: @yakobowski This just bit us (Frama-C) on a real run of analysis, and understanding the problem and its root was quite a challenge. On top of a mention in the documentation, detecting and warning at compile-time that the type of the marshalled value can contain exceptions somewhere would be a great help. |
Comment author: meyer Commit 13486, fixes the documentation part. |
Comment author: @alainfrisch Detecting at compile-time seems impossible in general. A runtime check would require some special representation of exception tags, but it is a good idea anyway (e.g. to fix the generic comparison). |
Comment author: @alainfrisch Work on the raise_variants branch changes the representation of exception tags and makes it possible to detect them during marshaling (tag = Object_tag, size = 2, first field points to a string value). |
Comment author: craff This is a real problem when using the parmap library. This should really work, I would increase a little the severity |
Comment author: @alainfrisch I'll re-classify this as a feature request. The documentation of Marshal is now rather explicit about extension constructors (and thus exceptions) loosing identity. |
This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc. |
I don't think the marshaler will ever respect external sharing in a way that would preserve exception identity across marshaling. Let us be realistic and close this feature wish. |
Original bug ID: 4978
Reporter: gerd
Status: acknowledged (set by @damiendoligez on 2014-07-31T11:47:46Z)
Resolution: open
Priority: normal
Severity: feature
Version: 3.11.1
Category: standard library
Duplicate of: #8399
Has duplicate: #6154
Related to: #7413
Monitored by: @glondu @yakobowski
Bug description
Looks like exceptions cannot be matched against after marshalling them:
exception S of int;;
exception S of int
let mk_s s = S s;;
val mk_s : int -> exn =
let dest_s (S s ) = s;;
Warning P: this pattern-matching is not exhaustive.
Here is an example of a value that is not matched:
exception
val dest_s : exn -> int =
dest_s (mk_s 42);;
dest_s (Marshal.from_string (Marshal.to_string (mk_s 42) []) 0);;
Exception: Match_failure ("", 1, 11).
The text was updated successfully, but these errors were encountered: