RE: [Caml-list] Static exception analysis or alternative to using exceptions

["David Allsopp" <dra-news@metastack.com>]

Mark Shinwell wrote:
> 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.

assert false is just a way of renaming the exception and relies on the
rather dirty (but necessary) hack in the compiler that, as a special case,
assert false is not optimised out of a program compiled without debugging
checks.

<snip>

> 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
> hacks.

Unnecessary verbosity = unreadable IMHO, that's one of the reasons we use
clear, functional languages in the first place. That overhead also isn't
negligible as soon as you've got a Hashtbl/Set/Map which is queried a lot
(i.e. just about any form of data processing). Code where you know a priori
that the keys exist becomes unnecessarily peppered with pointless match
clauses (or calls like ExtLib's Option.get which... would raise an exception
if faced with None!). The interest to me is not that the overhead is
negligible, but that it can be trivially removed by using a *better*
function in that instance. Obviously, in the perfect world, your call to the
_exc version would in reality carry a proof that the key will be found (and
so no exception would be necessary). I simply don't see that the overarching
reason to have the _exc version of the function would be simply for hacking
a quick solution to a problem where you can't be bothered to handle the
Not_found case.


David