English version
Accueil     Ŕ propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis ŕ jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml ŕ l'adresse ocaml.org.

Browse thread
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-31 (20:51)
From: Török_Edwin <edwintorok@g...>
Subject: Re: [Caml-list] Static exception analysis or alternative to using exceptions
On 05/31/2010 08:24 PM, David Allsopp wrote:
> Goswin von Brederlow wrote:
> <snip>
>>> However if the exception is, say, an I/O error reading a disk file,
>>> these should be thrown, and caught somewhere central where you can
>>> display an error message to the user (for GUI programs) or abort the
>>> current transaction (for server programs).  Recovering from such
>>> exceptions properly is still tricky though.  Since OCaml lacks
>>> 'finally', you either have to use a 'finally' impl from a library, or
>>> modify your code to not need it (eg. turning calls to 'open_in' and
>>> 'open_out' into a kind of continuation-passing style).  Or for small
>>> programs, abort the program and don't deal with recovery at all.
>>> All in all, this is not ideal for writing correct programs.  Some sort
>>> of exception analysis would be most welcome.
>> It would be nice if the possible exceptions of a function would be part of
>> the type. E.g.
>> let f1 () = raise Not_found
>> val f1 : unit -> 'a [ Not_found ]
>> let f2 () = try f1 () with Not_found -> () val f2 : unit -> unit
>> let f3 f = try f () with Not_found -> () val f3: (unit -> 'a [< Not_found
>> | 'B ]) -> 'a [ 'B ]
>> and so on.
>> Someone would have to write a new type system for that though.
> Would it be more practical to have that analysis as part of the .annot file?
> Presumably a patch which merged and updated the codebase of ocamlexc to
> produce exception-annotations in that manner might have a chance of making
> it into the OCaml compiler itself. I'm guessing that what you're getting at
> is the ability to see from your code that an exception could escape at any

pattern-match like exhaustive check that all cases are covered could be
with Not_found -> ...

error: exception catch clause is not exhaustive, exceptions not covered:

Maybe using a separate keyword, or a compile-time flag for this?

> given point rather than trying to add Java-style "checked exceptions" to
> OCaml?

I think there are 2 things to watch out when looking at Java and exceptions:
 - if a function throws too many exceptions, you sometimes see things
like "throws Exceptions", or "catch (Exception e) { // ignore }" in Java
code, which are completely useless, and might even lead to bugs
(silently ignoring all exceptions)
 - throwing an exception when a lookup doesn't find something is not
always the best. Look at Java's class loader which throws an exception
when a class is not found (pretty common when loading plugins) instead
of returning null.

I think that lookup functions should come in 2 flavours:
 - one that doesn't use exceptions (uses option types), for example
'find'. The key you are looking for may or may not be there
 - one that uses exceptions, for example 'get'. You know that the key is
there (or should be there), and you want the value. If the key isn't
there its probably a bug, or a very rare condition so the exception is
good here. I think the exception variant could even be generated
automatically as a wrapper to the option variant (not viceversa)

Best regards,