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
useful.
try
...
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,
--Edwin
_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
