PR#4978: Better wording.

git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@13568 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02

1 files changed, 6 insertions, 11 deletions

diff --git a/stdlib/marshal.mli b/stdlib/marshal.mli
index dab6bbb56..a87ae76e9 100644
--- a/stdlib/marshal.mli
+++ b/stdlib/marshal.mli
@@ -33,17 +33,12 @@
    Anything can happen at run-time if the object in the file does not
    belong to the given type.
 
-   Apart from that marshaling is not type-safe, it's also risky to
-   marshal exception or any OCaml values of type that contains
-   exception in its defininition or in dependent
-   definitions. Although it's possible to marshal and unmarshal these
-   OCaml values, it's not possible anymore to match the exception
-   contained in it using match construct. The same principle applies
-   to code that raises and catches OCaml values of type exn that has
-   been unmarshaled before . This limitation comes from the fact that
-   the exceptions have no defined run-time tag, therefore the system
-   is unable to asses the exception clause and match it. Other means
-   of using marshalled exceptions in OCaml code are not affected.
+   OCaml exception values (of type [exn]) returned by the unmarhsaller
+   should not be pattern-matched over through [match ... with] or [try
+   ... with], because unmarshalling does not preserve the information
+   required for matching their exception constructor. Structural
+   equalities with other exception values, or most other uses such as
+   Printexc.to_string, will still work as expected.
 
    The representation of marshaled values is not human-readable,
    and uses bytes that are not printable characters. Therefore,