[Caml-list] Exceptions considered harmful

[Caml-list] Exceptions considered harmful

[skaller]

On Tue, 2004-06-29 at 03:34, Markus Mottl wrote:
> On Tue, 29 Jun 2004, Martin Jambon wrote:
> > This makes me feel like we will not know if the "finally block" has been
> > completed or not. Why not totally prohibiting any exception raised from
> > the "finally block"?
> > 
> > let protect f x finally =
> >   let res =
> >     try f x
> >     with exc ->
> >       (try finally x with _ -> invalid_arg "protect")
> >       raise exc in
> >   (try finally x with _ -> invalid_arg "protect");
> >   res
> 
> But how do you know then that the exception came from "finally" and not
> from "f"?  You could even lose the information, whether "f" was executed
> successfully at all!

In general, I think exceptions are a bad idea.
I spend a lot of time removing them from my code :(

In a typical case it goes like this:

try 
  let f = open_in fname in
  do_something f;
  close_in f
with _ -> ()


Only this is very BAD code because it fails to isolate
two completely distinct possibilities for an error:
in opening the file, or in processing it: in the latter
case the file isn't closed: we didn't actually
expected a processing error here, and also fail to
correctly re-raise the exception.

This lack of localisation is quite hard to fix:

  let f = try open_in fname with _ -> () in
  do_something f;
  close_in f

WOOPS! that's a type error, which is good, because
we can't 'do_something' if the file wasn't opened.
What else can we try?

  try 
    let f = open_in fname in
    begin 
      try do_something f
      with _ -> close_in f 
    end;
    close_in f;
  with _ -> failwith "Do something failed"

WOOPS, we tried to close f twice. We can only do this:

  exception Some_error
  try 
    let f = open_in fname in
    begin 
      try do_something f
      with _ -> close_in f; raise Some_error
    end;
    close_in f;
   with Some_error -> raise Some_error
   | _ -> ()

but now we have lost the location and kind of the
error in something .. and we had to introduce a new
global exception as well. 

The obvious way to fix this mess is to eliminate the 
undesirable exceptions early:

  let result = 
    try Some (open_in fname) with _ -> None 
  in match result with
  | None -> ()
  | Some f -> 
    begin try do_something with x -> close_in f; raise x end
    close_in f

Of course, the result of the calculation here is unit,
more generally we'd be saying 

let result = do_something in close_in f; result

and obviously we'd be wrapping that as well.

Generally, the exceptions discard localisation
and destroy any kind of static assurance errors are handled.

To me, the Haskell monadic approach seems a sounder.

The problem with exceptions is that they're basically
without solid theoretical principles. Throwing out 
context is one thing .. recovering at an unknown
point, trapping unknown exceptions without any
aid from the type system simply defeats the purpose
of having a type system.

As far as I can see, just about the only way to
use exceptions properly is to eliminate them
at the earliest possible point .. which suggests
libraries simply shouldn't throw them.

It seems difficult to escape from deep recursions
without exceptions. They can be convenient.
They're useful for rapid prototyping where you
need a demo that works on some cases *fast*.

And they seem convenient when you 'know' there
can't be an error. The price is high. In avoiding
statically handling false negatives (errors that
can't occur) your code has become fragile: any change
which may in fact lead to raising an error will
not be discovered without testing.. and then it
will be very hard to find.

Would static exceptions be better? (Allow exceptions
but require that they're caught in an ancestor of the
scope they're raised in, and at least in a child of
the scope the exception is declared in)

Any comments on any of this appreciated.

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Exceptions considered harmful

[Lauri Alanko]

On Tue, Jun 29, 2004 at 11:02:49AM +1000, skaller wrote:
> Any comments on any of this appreciated.

The paper "Exceptional Syntax" by Nick Benton and Andrew Kennedy would
probably interest you. It's published in JFP 11(4), 2001, and an
electronic copy can probably be found somewhere in the net. They propose
an exception syntax that is closer to Haskell's monadic style: an
expression either returns a value or raises an exception, so catching an
exception is like pattern matching: there's one case for the returned
value, others for possible exceptions:

try 
  x <- foo ()
in
  bar ()
unless
  E1 -> handle1 ()
  E2 -> handle2 ()

To my mind this seems very sensible.


Lauri Alanko
la@iki.fi

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Exceptions considered harmful

[Christophe TROESTLER]

On Sun, 4 Jul 2004, Lauri Alanko <la@iki.fi> wrote:
> 
> an exception syntax that is closer to Haskell's monadic style: an
> expression either returns a value or raises an exception, so
> catching an exception is like pattern matching: there's one case for
> the returned value, others for possible exceptions:
> 
> try 
>   x <- foo ()
> in
>   bar ()
> unless
>   E1 -> handle1 ()
>   E2 -> handle2 ()

How is this sensibly different from OCaml' syntax?

try
  x <- foo();
  bar()
with
| E1 -> handle1()
| E2 -> handle2()

ChriS

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Exceptions considered harmful

[Michael Hicks]

> try
>   x <- foo ()
> in
>   bar ()
> unless
>   E1 -> handle1 ()
>   E2 -> handle2 ()

The key part to this approach is that bar() is not covered by the 
exception handler.   This allows the caller to communicate the 
successfully created value into bar() through x.  In a traditional 
setting, you'd have something like

let x := NONE;
try
   x := SOME foo();
with E1 -> ....

if !x <> NONE then bar !x
else ??

Mike

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Exceptions considered harmful

[skaller]

On Mon, 2004-07-05 at 06:24, Michael Hicks wrote:
> > try
> >   x <- foo ()
> > in
> >   bar ()
> > unless
> >   E1 -> handle1 ()
> >   E2 -> handle2 ()
> 
> The key part to this approach is that bar() is not covered by the 
> exception handler. 

Yeah, this is just an extension of let/in:

let x = foo () in bar () unless ...

however it is still dynamic = statically insecure =
unable to reason about the code locally = bad,
however increased localisation is obtained:
you have more idea where the exception came from
so this does seem better.

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

[Caml-list] Re: Exceptions considered harmful

[Richard Cole]

When I read your examples I wondered how often this situation arises. Is 
it just a symptom of the file interface or is it more general? It occurs 
whenever resources, such as a file descriptor, need to be relinquished, 
which generally is pretty often.

In one programming task that I worked on for some time most of the code 
followed the following pattern.

   1. allocate resources
   2. manipulate resources
   3. free resources

In each step you have to be ready for something to go wrong. Since it 
was in a distributed environment steps 1 2 and 3 were composed of 
concurrent parts, i.e. all resources were allocated concurrently.

In other programming tasks it has not been important to catch errors 
because the effect of the programming stopping or leaking a few 
resources is not serious.

But if you have to catch the errors it is tedious and error prone to 
write massive try catch blocks to catch every error. Our solution was to 
use the command pattern.

type success_or_failure = Success | Failure
class type command =
   method do: clipboard -> success_or_failure
   method undo: clipboard -> unit
   method final: clipboard -> unit
end ;;

Then programs became the construction of object like the following:

let copy_file_cmd_name_args src dst =
   let src_cmd = open_file_cmd src in
   let dst_cmd = open_file_cmd dst in
     seq_execute_cmd [
        par_execute_cmd [src_cmd, dst_cmd],
        copy_file_cmd_fd_func_args src_cmd#file dst_cmd#file
     ];

Here serial_execute runs through the commands executing them one by one 
until either it finishes or an error is generated in which case it backs 
out by calling undo. Finally objects are given a chance to release 
resources when final is called.

This way we were sure that resources would be properly accounted for. Of 
course hardware faults or mis-behaving clients can still cause you 
trouble. Particularly tracing which operation first caused a failure and 
what conditions lead to that failure.

It seems to me that if you have to catch errors then you have to 
construct some similar framework in Ocaml. There's no language support 
for writing commands.

regards,

Richard.

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners