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
Re: [Caml-list] Static exception analysis or alternative to using exceptions
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2010-05-27 (09:11)
From: Mark Shinwell <mshinwell@j...>
Subject: Re: [Caml-list] Static exception analysis or alternative to using exceptions
On Thu, May 27, 2010 at 09:54:29AM +0100, David Allsopp wrote:
> Florent Ouchet wrote:
> > Same here, specially to avoid the Not_found exception.
> > The optional return values gives the oportunity to have a clear view of
> > what is being done if the result is not available.
> Agreed - though [find] is one of the examples where you do need find and
> find_exc - because often there are occasions where before calling
> {Map,Set,Hashtbl}.find you already know that the key exists and so won't
> fail at which point the 'a option boxing is a waste of time and space and
> Not_found would be a truly exceptional situation so passes the previously
> mentioned test.

I don't think I agree with this.  I would argue that for the majority of
programs it is likely that the extra overhead is in fact negligible.  In
the cases where it should be impossible to get the None return value, I
think that should probably be annotated as such in the code with "assert
false", which would seem to be more appropriate than a random Not_found
popping up at some much higher level.

In some cases it might be possible to refactor the code to just avoid the
situation entirely, for example by turning this:

  if not (Map.mem my_map key) then
    let data = Map.find_exn my_map key in

into this:

  match Map.find my_map key with
  | None -> ..a..
  | Some data -> ..b.. ..c..

Whilst I agree that there are arguments relating to verbosity of the use
of option types, I think the strongest argument for keeping the *_exn
variants may actually be that they're just a lot more convenient for quick