Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
[OSR] Exceptionless error management, take 2
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2008-02-10 (12:35)
From: tab@s...
Subject: Re: [Caml-list] [OSR] Exceptionless error management, take 2
On Fri, Feb 08, 2008 at 01:40:09PM +0100, Bünzli Daniel wrote:
> Only if they have exactly the same error cases (in which case they are very 
> likely to attach the same semantics to it). I think you fail to think 
> realisitically, chances are little that this is going to pose any problems 
> in practice.

with growing use of polymorphic variant everywhere, like lots of people
suggest, i can see the number of "collision" raising quickly. specially
defining for regular usage stuff like `Error `Succeed, very common

> Do you redefine the option type in each of your modules to be 
> able to say this is an optional integer from module X ?

no, for the simple reason that the option type is (almost) a built-in
type. it could be abuse yes, but everyone knows it's a shared type. like
integer or string.

the "integer 1" is the same in every module, the "error of integer 1" is
probably different.

for example,
in unix: "Error of 1" would means EPERM
in xml: "Error of 1" would means error line 1.

If you working with normal variant, the compiler knows it can't compare
Unix.Error and Xml.Error even though they have the same type attached
(an integer). with polymorphic variant, there's only "`Error of integer"
in both module, so for the compiler they are the same.

>> If I use normal variant, the compiler will prevent me using the same code 
>> to match a X.Error and a Y.Error.
> Note that with this take 2 proposal -- that I personnaly find too invasive 
> and heavy weight  -- you won't get that, you will have to match on 
> Error.Error (!) instead of `Error (take 1).

it all boils down in where the thing is going to end up or how it's
going to be use.

Vincent Hanquez