Static exception analysis or alternative to using exceptions

Static exception analysis or alternative to using exceptions

[Hans Ole Rafaelsen]

[-- Attachment #1: Type: text/plain, Size: 911 bytes --]

Hi,

when running server software, it is quite frustrating when the program
crashes due to an uncaught exception. I see there was some attempts on doing
static analysis of the exception flow in programs around 10 years ago (such
as ttp://pauillac.inria.fr/caml/ocamlexc/ocamlexc.htm), but they did not
seem to be complete and now seem to be dropped. Is there some technical
reason for not having static exception analyses, or can we hope that some
day in the future, Ocaml will support static exception analysis?

What experience does people have to using alternatives to exceptions, such
as option types or exception monads? Does use of third part libraries that
still throws exceptions make such approaches hard to use? Performance wise
it seems to be comparable to catching exceptions or matching for options, so
I guess the difference be might a question of programming style?


Thanks,

Hans Ole Rafaelsen

[-- Attachment #2: Type: text/html, Size: 1013 bytes --]

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

[Alain Frisch]

On 05/26/2010 06:15 PM, Hans Ole Rafaelsen wrote:
> What experience does people have to using alternatives to exceptions,
> such as option types or exception monads? Does use of third part
> libraries that still throws exceptions make such approaches hard to use?
> Performance wise it seems to be comparable to catching exceptions or
> matching for options, so I guess the difference be might a question of
> programming style?

Indeed, this is mostly a matter of taste and style.

My personal "Rule #1" to decide to use exceptions or not is that one:

  Raising an exception is ok if you know where it will be caught
  or which global effect it will have on the application.


This includes the following cases:

- (Short jumps) Using exceptions locally as shortcuts in loops or more 
complex  algorithms. In that case, the runtime exception is encapsulated 
in a function or module, and should not cause any harm.

- (Long jumps) Using exceptions to report unexpected errors, to which 
the application has little chance to react in a clever way except 
displaying some error messages to the screen or to a log file. The catch 
point is a global exception handler, even though the code raising the 
exception (maybe in a general purpose library) might not know exactly 
how the application will react to the exception.  It is much better if 
the exception describes the problems in terms that can be understood by 
a human (Not_found, even with a stack trace, is not very helpful as an 
error message).

Library function that perform some kind of lookup should return an 
option type and let the caller raise a proper exception to report error 
in a way that makes sense for the application. Similarly for other kind 
of functions that can "fail": use a sum type (or polymorphic variants) 
instead to describe the possible "errors". A variant of the function 
that raises an exception is acceptable for cases where the caller really 
expect the function to succeed (it can fail only because of bugs in the 
application, not because of user or system errors). In that case, 
Assert_failure, or a custom exception, is probably better than 
Not_found. More generally, if exceptions are to be used, custom ones are 
usually better than generic ones (Failure, Invalid_argument).

Another interesting use of exceptions comes from the fact that exn is an 
extensible sum type. (Unfortunately, it is the only one in OCaml.) This 
enables some kinds of loosely typed scenarios, like notification 
messages to be dispatched across global objects in the application: the 
list of possible messages is not fixed in advance, and each object can 
simply use pattern matching to react on messages it is interested in. 
But this is another story...



Alain

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

[Richard Jones]

On Wed, May 26, 2010 at 06:15:05PM +0200, Hans Ole Rafaelsen wrote:
> What experience does people have to using alternatives to exceptions, such
> as option types or exception monads? Does use of third part libraries that
> still throws exceptions make such approaches hard to use? Performance wise
> it seems to be comparable to catching exceptions or matching for options, so
> I guess the difference be might a question of programming style?

Personally I've found that you should only throw those exceptions
which can be caught in a single place in the program.  By this I mean
that an exception such as Not_found shouldn't be thrown, and instead
it would be better to use an option type (for stdlib functions which
throw Not_found, you have to be _very_ careful that the exception
cannot "escape").

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.

Rich.

-- 
Richard Jones
Red Hat

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

[Dario Teixeira]

Hi,

> Personally I've found that you should only throw those exceptions
> which can be caught in a single place in the program.  By this I mean
> that an exception such as Not_found shouldn't be thrown, and instead
> it would be better to use an option type (for stdlib functions which
> throw Not_found, you have to be _very_ careful that the exception
> cannot "escape").

Yes, I agree.  As an illustration, dictionary lookup functions such as
Map.find should return an option type, but use exceptions for truly
exceptional circumstances that no sane programmer should have to watch
for at every single invocation (say, "raise Dictionary_eaten_by_bears").

Cheers,
Dario Teixeira

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

[Goswin von Brederlow]

Richard Jones <rich@annexia.org> writes:

> On Wed, May 26, 2010 at 06:15:05PM +0200, Hans Ole Rafaelsen wrote:
>> What experience does people have to using alternatives to exceptions, such
>> as option types or exception monads? Does use of third part libraries that
>> still throws exceptions make such approaches hard to use? Performance wise
>> it seems to be comparable to catching exceptions or matching for options, so
>> I guess the difference be might a question of programming style?
>
> Personally I've found that you should only throw those exceptions
> which can be caught in a single place in the program.  By this I mean
> that an exception such as Not_found shouldn't be thrown, and instead
> it would be better to use an option type (for stdlib functions which
> throw Not_found, you have to be _very_ careful that the exception
> cannot "escape").

Which needlessly complicates your code when it never happens.

Imho a good module should provide both an exception and option based
interface to fit the circumstances and programming style.

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

MfG
        Goswin

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

[Florent Ouchet]

Goswin von Brederlow a écrit :
> Imho a good module should provide both an exception and option based
> interface to fit the circumstances and programming style.
>
>   
+1

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

ocamlexc gave such results, but this tool is now discontinued and not 
compatible with latest compilers :(

-- 
Florent Ouchet
PhD Student
CIS/VDS Team - TIMA Laboratory

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

[David Allsopp]

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
given point rather than trying to add Java-style "checked exceptions" to
OCaml?


David

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

[Nicolas Pouillard]

On Mon, 31 May 2010 16:36:22 +0200, Goswin von Brederlow <goswin-v-b@web.de> wrote:
> Richard Jones <rich@annexia.org> writes:
> 
> > On Wed, May 26, 2010 at 06:15:05PM +0200, Hans Ole Rafaelsen wrote:
> >> What experience does people have to using alternatives to exceptions, such
> >> as option types or exception monads? Does use of third part libraries that
> >> still throws exceptions make such approaches hard to use? Performance wise
> >> it seems to be comparable to catching exceptions or matching for options, so
> >> I guess the difference be might a question of programming style?
> >
> > Personally I've found that you should only throw those exceptions
> > which can be caught in a single place in the program.  By this I mean
> > that an exception such as Not_found shouldn't be thrown, and instead
> > it would be better to use an option type (for stdlib functions which
> > throw Not_found, you have to be _very_ careful that the exception
> > cannot "escape").
> 
> Which needlessly complicates your code when it never happens.
> 
> Imho a good module should provide both an exception and option based
> interface to fit the circumstances and programming style.

Since having all functions in all flavours can lead to hard to interface
bloat, one should consider tiny functions to switch from a style to another.
It tends to be easier to start from an option type in the case of Not_found
instead of the other way around for the following reason:

  * The typechecker does not remind us to catch the exception.
  * We need a custom handler per exception.
  * We need to take a thunk to delay the computation.

  let not_found_to_option f =
    try Some (f ())
    with Not_found -> None

On the contrary look at:

  let from_option exn = function
    | Some x -> x
    | None -> raise exn

  Example: from_option Not_found (List.find p xs)

Best regards,

-- 
Nicolas Pouillard
http://nicolaspouillard.fr

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

[Christophe Raffalli]

[-- Attachment #1: Type: text/plain, Size: 1345 bytes --]


> 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.
>   
This is what PML does ... and what is nice is that is does not even
require the exception to be garded ...
>
> Someone would have to write a new type system for that though.
>   
Yes, but this require very little new technology : a function having one
type or two as return type is basically the same ...
and polymorphic variant are very well suited to be the default practice
for exception (as in your f3 example).

The only questions (I think) are
- complexity of the algorithm (I think it shoud be OK)
- readability of inferred types (one could hide exception types by
default ?)
 
Cheers,
Christophe

> MfG
>         Goswin
>
> _______________________________________________
> 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
>   



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]

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

[Török Edwin]

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

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

[Lukasz Stafiniak]

On Mon, May 31, 2010 at 9:30 PM, Nicolas Pouillard
<nicolas.pouillard@gmail.com> wrote:
>
> Since having all functions in all flavours can lead to hard to interface
> bloat, one should consider tiny functions to switch from a style to another.
> It tends to be easier to start from an option type in the case of Not_found
> instead of the other way around for the following reason:
>
>  * The typechecker does not remind us to catch the exception.
>  * We need a custom handler per exception.
>  * We need to take a thunk to delay the computation.
>
>  let not_found_to_option f =
>    try Some (f ())
>    with Not_found -> None
>
> On the contrary look at:
>
>  let from_option exn = function
>    | Some x -> x
>    | None -> raise exn
>
>  Example: from_option Not_found (List.find p xs)
>

I use a syntax extension that catches "Not_found" and raises a failure
instead, with the source location of the "real" offending call. I do
this mostly because OUnit catches exceptions so backtraces are of no
use. When I use the unmodified calls, I always handle Not_found right
away, close to call point -- either by directly catching it, or by
using a higher-order function, like an iterator that expects Not_found
instead of None from the callee. Anyway, I vote for "option"ising all
of the standard library and providing the function "unsome" raising a
string with source code location of its call.

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

[blue storm]

> I use a syntax extension that catches "Not_found" and raises a failure
> instead, with the source location of the "real" offending call. I do
> this mostly because OUnit catches exceptions so backtraces are of no
> use.

I have encoutered the same problem and resolved it with explicit
backtrace handling in Printexc. I use the following function wrapper :

let verbose_func func x =
    try func x with exn ->
      Printf.printf "Test error %s\n%!" (Pinrtexc.to_string exn);
      Printf.printf "%s\n%!" (Printexc.get_backtrace ());
      raise exn in

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

[Goswin von Brederlow]

"David Allsopp" <dra-news@metastack.com> writes:

> 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
> given point rather than trying to add Java-style "checked exceptions" to
> OCaml?
>
>
> David

It want it to fail to compile if the interface specifies one set of
exception and the code produces another that is incompatible. The
following should not compile:

module M : sig
  val f : int -> int []
end = struct
  let h = Hashtbl.create 0
  let f x = Hashtbl.find x
end

Since Hashtbl.find can throw Not_found and the function does not catch
that the function still can throw Not_found. This violates the
declaration in the signature that says it never throws an exception.

This goes beyond just annotating what exception can be thrown. It should
do a real validation.

MfG
        Goswin