Today's inflamatory opinion: exceptions are bad

Today's inflamatory opinion: exceptions are bad

[Brian Hurt]

I think I've come to the conclusion that exceptions are bad.

In Ocaml, they're useless in many cases, and in most cases wrong. 
Avoiding them generally makes for better code.  There are two vague types 
of exceptions- those the program can, and probably should- handle, and 
those that the program can't, and probably should even try to, handle.

For the former, returning a variant type ('a option if nothing else) is a 
better idea, for (at least) two reasons.  One, the type system enforces 
the requirement to actually handle the error, at the location the return 
value of the function is desired.  Want the result?  Handle the errors. 
Which allow a function to "pass along" an error if it wants to.  So you 
could still write functions like:

let getline ?channel () =
 	match filedesc with
 		| Some(c) -> input_line c
 		| None -> (* read from stdin *) read_line ()
;;

The second reason is that match ... with doesn't break tail recursion, 
while try ... with does.  This code is not tail recursive:

let rec echo_file channel =
 	try
 		begin
 			let line = input_line channel in
 			print_string (line ^ "\n");
 			echo_file channel
 		end
 	with
 		| End_of_file -> ()
;;

Call this on a very long file, and you'll blow stack.  But if input_line 
returned, say, string option (where None meant end of file), the natural 
code would be:

let rec echo_file channel =
 	match input_line channel with
 		| Some(line) ->
 			begin
 				print_string (line ^ "\n");
 				echo_file channel
 			end
 		| None -> ()
;;

This is tail recursive.  This is probably the number one bug hit by 
newbies- "I tried to read in a big file and Ocaml blew up!"  The work 
around to this is to basically implement the function:

let fixed_input_line channel =
 	try
 		Some(input_line channel)
 	with
 		| End_of_file -> None
;;

and call it instead.  Except often times this function is hand-inlined and 
only serves to obfuscate the code.

string option probably isn't the best type for input_line to return, as 
reading can cause other errors.  But this just proves my point even more:

let rec echo_file channel =
 	match input_line channel with
 		| Input(line) ->
 			begin
 				print_line (line ^ "\n");
 				echo_file channel
 			end
 		| End_of_file -> ()
 		| Read_error(desc) ->
 			begin
 				print_line ("Read error: " ^ desc ^ "\n");
 				()
 			end
;;

Note that this leaves the door open to sharing a single variant type among 
all the input functions:

type 'a input =
 	| Input of 'a
 	| End_of_file
 	| Read_error of string
;;

So that input_line returns string input, input_char char input, input_int 
int input, and so on.

This does force error handling to be *somewhat* local, but I think this is 
a good thing, not a bad thing.  The farther away the error handling is 
from the error source, the harder it is to figure out what caused the 
error, and what to do about it (other than just die).  If that's the 
behavior I want, it's easy to just do:
 	| Read_error (_) -> exit (-1)

The other type of exception is exemplified by the out of memory condition. 
In 30+ years of using computers and 10+ years of professionally 
programming them, I think I've seen two programs that gracefully and 
correctly handled the out of memory condition by doing something other 
than just exiting the program.  And both of those programs assumed the OOM 
condition occured because of leaked memory, and thus by rolling back and 
starting over memory could be reclaimed.  The solution there is to not 
leak memory- garbage collection is a wonderfull thing.

As a general rule, if your program is running out of memory, you're trying 
to solve too big of a problem.  If you're trying to invert a 30k by 30k 
matrix on a 32-bit machine, it just isn't going to work.  And long before 
you run out of memory, you're generally going to push the machine into 
swapping and make it unusably slow, so if you're wanting to put a limit on 
the size of problems a program can handle, the limit should probably be 
well before the out of memory condition happens.

There's one other system level error (i.e. generated by an interrupt) I 
can think of the program handling: fp errors, if you're using signalling 
fp.  Maybe.  The thing is that these errors are synchronous, they happen 
at specific points in the code and arise because of something specific the 
code does.  Which means, if you're using these, you want to know where and 
why the problem happened- and generally you want to know more than just 
"divide by zero on line 29 of mat_invert".  And tail call optimization 
makes it hard to figure out how you got there in the general case.

I suppose you could want to write code like "normally use conjugate 
gradiant, unless you hit a problem, in which case back off and do the much 
more numerically stable (if slower) gaussian elimination", with the 
definition of "problem" being "hit a signalling float".  But this is very 
much the exception that proves the rule- this is how rarely exceptions are 
usefull.

Other system level errors?  Things like bounds check violations, or 
integer divide by zeros?  These are programatic errors, and generally 
catching them in the program doesn't help.

There's one other use for exceptions I've seen (and done)- using them as 
non-local longjmps.  A classic example for this is a delete functions on a 
tree structure- you recurse all the way down to the leafs and discover 
that you're not deleting anything at all, what do you do?  I sometimes 
(too often) throw an exception to jump out of the recursion back up to the 
top level.

The fact that I always feel dirty when I do this, and feel the need to 
include a comment defending this decision is, I think, indicative ("Hmmm. 
This means something!" -- Closet Encounters of the Nerd Kind).  Or I could 
just be having a Pascal flashback (the language, not the coworker).

My point here is this: Ocaml is not Java (a fact we should all be 
gratefull for, IMHO).  Simply because Java and C++ do something, doesn't 
mean that it's a good thing to do.

Major changes to the language itself I see as unlikely in the near term. 
I'm mainly putting this rant out there to a) generate discussion, b) make 
people think, and c) maybe influence the design of future Ocaml libraries 
and code.

Brian

Re: [Caml-list] Today's inflamatory opinion: exceptions are bad

[skaller]

On Sat, 2006-12-09 at 20:42 -0500, Brian Hurt wrote:
> I think I've come to the conclusion that exceptions are bad.

Surely this has been known for at least 10 years -- qualified
by the comment "in the form they're in at the moment in most
languages".

Exceptions are basically a way to escape context, and possibly
restart in an old context with a new continuation.

Static exceptions are just fine, that is, those where you
have a 'catch' which is visible at the throw point.

But with full dynamic exceptions, there's no assurance of this.

What Felix does is: it provides 'static exceptions' (actually
it is a non-local goto), but you can wrap them in a function
and pass a closure in the usual way.

This ensures you cannot throw an exception which is not caught,
and factors the static and dynamic parts of the 'path' of the
thrown exception. The cost is passing the closure as an argument
explicitly everywhere: both more typing for the programmer
and loss of performance.


> For the former, returning a variant type ('a option if nothing else) is a 
> better idea, for (at least) two reasons. 

The main difficulty with this is the syntax of matches.

In 'micky mouse' cases it is easy:

> let getline ?channel () =
>  	match filedesc with
>  		| Some(c) -> input_line c
>  		| None -> (* read from stdin *) read_line ()


But in REAL code 'the rest of the program' has to go
where you wrote 'input_line c'.

So you either suffer HUGE matches or you have to pass
a LOT of context explicitly to an external function.

In Ocaml it is every worse, since only 'let rec' allows
you to ignore order of writing of functions, and that
cannot span module boundaries easily (yeah, i know that
is being worked on).

Ocaml has a number of things which make matches better than
'standard' match syntax -- polymorphic variants allow
handling whole groups of cases, and alternatives can be
joined provided they share arguments and guards.

These things help (thanks!) but they aren't enough to
reduce clutter to the same extent as exceptions do.


> let fixed_input_line channel =
>  	try
>  		Some(input_line channel)
>  	with
>  		| End_of_file -> None
> ;;
> 
> and call it instead.  

That is useless in general .. see below ..

> Except often times this function is hand-inlined and 
> only serves to obfuscate the code.

In Felix I sometimes get 'Not_found' exception .. and I am using
hundreds of Hashtbl.find table key which I have to 'hand annotate'
with code like

	begin try Hashtbl.find table key 
	with Not_found -> print_endline "ERROR "; raise MyError
	end

Your function above is actually useless, because it doesn't
have an argument representing the current location in the
code, nor does it allow a flexible error handling policy.

These cases are usually real errors, I don't want any None
case I just want to know where the error occurred. However
sometimes  I have:

	begin Hashtbl.find table key with Not_found -> [] end

and that tends to be written out literally every time. Large
numbers of named functions make for unreadable code too,
require extra work to propagate across compilation unit
boundaries, and can make a mess of your build system
in Ocaml (because you really have to define that
function in the first translation unit that uses it,
since Ocaml can't propagate functions backwards).

> This does force error handling to be *somewhat* local, but I think this is 
> a good thing, not a bad thing.  

I think that is only half the story. Localisation is a key
concept in programming -- one which researchers don't seem
to have paid much attention to.

The implication is that if there are case where you want
thing localised .. there are cases where you don't :)

Most C++ programmers will tell you exceptions provide a welcome
relief from C error handling.

So I would put the issue more like: programmers need
control over the localisation.

For example in Haskell you could use a monad to obtain a secure,
well principled, but 'not so local' way of handling
exceptions.


> The farther away the error handling is 
> from the error source, the harder it is to figure out what caused the 
> error, and what to do about it (other than just die).  If that's the 
> behavior I want, it's easy to just do:
>  	| Read_error (_) -> exit (-1)

Felix libraries do that. If there's a program error ..
it just aborts. 

> I suppose you could want to write code like "normally use conjugate 
> gradiant, unless you hit a problem, in which case back off and do the much 
> more numerically stable (if slower) gaussian elimination", with the 
> definition of "problem" being "hit a signalling float".  But this is very 
> much the exception that proves the rule- this is how rarely exceptions are 
> usefull.

I agree with your sentiments, but not the implied argument.

Basically we have exceptions because we have stacks.

If we did everything on the heap, and used continuations,
there would be no need for exceptions. Instead you'd just
choose which continuation to run next.

With that kind of programming model, especially one supported
with multiple threads of control (such as in Felix) new
development paradigms develop. If I may give just one example,
consider GLR parsing. Instead of backtracking -- which for
parsers cannot be generalised using a stack -- you spawn
parser threads.

With a suitable tool, you can do this .. but it is quite
hard to do natively -- the stack gets in the way, time
and again.

> The fact that I always feel dirty when I do this, and feel the need to 
> include a comment defending this decision is, I think, indicative ("Hmmm. 
> This means something!" -- Closet Encounters of the Nerd Kind).  

Lol!

> My point here is this: Ocaml is not Java (a fact we should all be 
> gratefull for, IMHO).  Simply because Java and C++ do something, doesn't 
> mean that it's a good thing to do.

Ocaml has exceptions because it uses a stack model.

It has 'bad' exceptions because that's all we really know
how to do. Perhaps an expert would comment but I see
activity on delimited continuations (which I don't understand)
which looks like it is making progress.

> Major changes to the language itself I see as unlikely in the near term. 

IMHO: The Ocaml team has shown a willingness -- even eagerness -- to
make quite major changes -- polymorphic variants, labelled arguments
being two that come to mind. Some are less obvious but probably
also classify in terms of difficulty, such as inter-module
recursion.

But for changes you have to remember they're French!

"It works in practice .. but does it work in theory?"


-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net

Re: [Caml-list] Today's inflamatory opinion: exceptions are bad

[Martin Jambon]

On Sat, 9 Dec 2006, Brian Hurt wrote:

> I think I've come to the conclusion that exceptions are bad.

Unfortunately, there are exceptions to this rule.
:-)


Martin

--
Martin Jambon, PhD
http://martin.jambon.free.fr

Re: [Caml-list] Today's inflamatory opinion: exceptions are bad

[Chris King]

On 12/9/06, Brian Hurt <bhurt@spnz.org> wrote:
> The second reason is that match ... with doesn't break tail recursion,
> while try ... with does.  This code is not tail recursive:
>
> let rec echo_file channel =
>        try
>                begin
>                        let line = input_line channel in
>                        print_string (line ^ "\n");
>                        echo_file channel
>                end
>        with
>                | End_of_file -> ()
> ;;

I'm a big fan of Martin Jambon's "let try" syntax extension [1].  With
it the above construct can be written as:

let rec echo_file channel =
    let try line = input_line channel in
    print_string (line ^ "\n");
    echo_file channel
    with End_of_file -> ()

and would be tail-recursive.  More often than not this is how I want
to write my exception handlers.


> My point here is this: Ocaml is not Java (a fact we should all be
> gratefull for, IMHO).  Simply because Java and C++ do something, doesn't
> mean that it's a good thing to do.

One thing Java (sort of) gets right is keeping track of which
exceptions a function can throw, making it easy to ensure that some
deeply nested piece of code won't cause the entire application to die
from some obscure exception.  I'd love to see a similar feature in
O'Caml, whereby the exceptions which a function can raise are part of
its type and are inferred and checked by the compiler.  For example:

val List.assoc: 'a -> ('a * 'b) list -> 'b raises Not_found
val List.iter: ('a -> unit raises 'b) -> 'a list -> unit raises 'b

This would make it easy to spot which exceptions go uncaught in the
main function of a program (perhaps the compiler could even emit a
warning in this case), as well as allowing the programmer to ensure
that certain pieces of code won't raise arbitrary exceptions.  As an
example of the latter, a stricter version of List.iter could have the
type:

val iter_until: ('a -> unit raises Exit) -> 'a list -> unit

Of course, this system would probably require that type exn be
eschewed for something closer to a polymorphic variant so that typing
in 'catch' statements will work correctly.  Then types such as

val catch_failures: ('a -> 'b raises [Failure of string | 'c]) -> 'a
-> 'b raises 'c

would be possible.

- Chris

[1] http://martin.jambon.free.fr/extend-ocaml-syntax.html#lettry

Re: [Caml-list] Today's inflamatory opinion: exceptions are bad

[malc]

On Sat, 9 Dec 2006, Brian Hurt wrote:

>
> I think I've come to the conclusion that exceptions are bad.
>
> In Ocaml, they're useless in many cases, and in most cases wrong. Avoiding 
> them generally makes for better code.  There are two vague types of 
> exceptions- those the program can, and probably should- handle, and those 
> that the program can't, and probably should even try to, handle.
>
> For the former, returning a variant type ('a option if nothing else) is a 
> better idea, for (at least) two reasons.  One, the type system enforces the 
> requirement to actually handle the error, at the location the return value of 
> the function is desired.  Want the result?  Handle the errors. Which allow a 
> function to "pass along" an error if it wants to.  So you could still write 
> functions like:

[..snip..]

Guess there's third type, code might detect catastrophic failure
during the run of custom block finalizer, in which case, should there
be a need for a cleanup actions, raising an exception might be the
only choice, however i couldn't say offhand whether OCaml allows to
raise exceptions in this context at all.

--
vale

Re: [Caml-list] Today's inflamatory opinion: exceptions are bad

[Jon Harrop]

On Sunday 10 December 2006 03:35, Chris King wrote:
> > My point here is this: Ocaml is not Java (a fact we should all be
> > gratefull for, IMHO).  Simply because Java and C++ do something, doesn't
> > mean that it's a good thing to do.
>
> One thing Java (sort of) gets right is keeping track of which
> exceptions a function can throw, making it easy to ensure that some
> deeply nested piece of code won't cause the entire application to die
> from some obscure exception.  I'd love to see a similar feature in
> O'Caml, whereby the exceptions which a function can raise are part of
> its type and are inferred and checked by the compiler.

This has been done. There was a tool called ocamlexc that did whole-program 
analysis to find out which exceptions could propagate where. However, it 
wasn't useful enough to be kept up to date.

  http://caml.inria.fr/pub/old_caml_site/ocamlexc/ocamlexc.htm

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists

Re: [Caml-list] Today's inflamatory opinion: exceptions are bad

[malc]

On Sun, 10 Dec 2006, malc wrote:

> On Sat, 9 Dec 2006, Brian Hurt wrote:
>
>> 
>> I think I've come to the conclusion that exceptions are bad.
>> 
>> In Ocaml, they're useless in many cases, and in most cases wrong. Avoiding 
>> them generally makes for better code.  There are two vague types of 
>> exceptions- those the program can, and probably should- handle, and those 
>> that the program can't, and probably should even try to, handle.
>>

[..snip..]

And also there is `new' and, to the best of my knowlege, it's not
possible to return a `class option' should one want to dwelve into
O of Caml.

--
vale

Re: [Caml-list] Today's inflamatory opinion: exceptions are bad

[Jon Harrop]

On Sunday 10 December 2006 01:42, Brian Hurt wrote:
> I think I've come to the conclusion that exceptions are bad.

:-)

> For the former, returning a variant type ('a option if nothing else) is a
> better idea, for (at least) two reasons.  One, the type system enforces
> the requirement to actually handle the error, at the location the return
> value of the function is desired.

Being forced to handle errors immediately and then implement your own 
backtracking is not necessarily a good thing. In particular, it can make your 
code substantially more verbose, less clear and less efficient.

> Call this on a very long file, and you'll blow stack.  But if input_line
> returned, say, string option (where None meant end of file), the natural
> code would be:
> ...
> The work around to this is to basically implement the function:

It is often better to resort to imperative programming in that case:

  let list = ref [] in
  (try
     while true do
       list := input_line stdin :: !list
     done
   with End_of_file -> ());
  !list;;

> Note that this leaves the door open to sharing a single variant type among
> all the input functions:
>
> type 'a input =
>
>  	| Input of 'a
>  	| End_of_file
>  	| Read_error of string

I don't want to have to handle all exceptional circumstances at every step of 
the computation.

> There's one other use for exceptions I've seen (and done)- using them as
> non-local longjmps.  A classic example for this is a delete functions on a
> tree structure- you recurse all the way down to the leafs and discover
> that you're not deleting anything at all, what do you do?  I sometimes
> (too often) throw an exception to jump out of the recursion back up to the
> top level.

That is a productive optimisation in OCaml. The alternative would be to 
perform physical equality tests all the way back up the recursion just to 
avoid reallocating identical trees.

The same optimisations crops up all over the place. Rewrite systems can do the 
same thing to avoid rewriting identical expressions.

> Major changes to the language itself I see as unlikely in the near term.
> I'm mainly putting this rant out there to a) generate discussion, b) make
> people think, and c) maybe influence the design of future Ocaml libraries
> and code.

The F# language is related to OCaml and runs under .NET. With 
Microsoft's .NET, exceptions are very expensive. Consequently, there is an 
immediate problem converting OCaml code to F# code because it is likely to 
run very slowly if it uses functions like "find" and "assoc". However, I'm 
sure which I prefer. I am certainly used to OCaml's lightweight exceptions 
and use them all over the place.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists

Re: [Caml-list] Today's inflamatory opinion: exceptions are bad

[Andreas Rossberg]

"Brian Hurt" <bhurt@spnz.org> wrote:
>
> For the former, returning a variant type ('a option if nothing else) is a 
> better idea, for (at least) two reasons.  One, the type system enforces 
> the requirement to actually handle the error, at the location the return 
> value of the function is desired.  Want the result?  Handle the errors.

I guess Joe Armstrong (of Erlang fame) would have to say a lot about how to 
deal with failure properly. According to him, and the seemingly successful 
Erlang philosophy (which is, "let it crash"), attempts to locally handle 
errors are exactly the wrong approach. See his very insightful thesis.

> My point here is this: Ocaml is not Java (a fact we should all be 
> gratefull for, IMHO).  Simply because Java and C++ do something, doesn't 
> mean that it's a good thing to do.

Now, ML had exceptions before C++ was even called C++, and one and a half 
decades before anybody ever heard of Java. In fact, Stroustrup says that C++ 
exceptions were inspired by ML (too bad he did not take more inspiration 
from there :) ). ML took the concept from CLU, IIRC, which was a language 
particularly designed to improve various aspects of large scale software 
engineering.

- Andreas

Re: [Caml-list] Today's inflamatory opinion: exceptions are bad

[Tom]

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

>
>
> I guess Joe Armstrong (of Erlang fame) would have to say a lot about how
> to
> deal with failure properly. According to him, and the seemingly successful
> Erlang philosophy (which is, "let it crash"), attempts to locally handle
> errors are exactly the wrong approach. See his very insightful thesis.
>

Would you please be so kind as to appoint us to the very thesis you have in
mind?

- Tom

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

Re: [Caml-list] Today's inflamatory opinion: exceptions are bad

[Andreas Rossberg]

"Tom" <tom.primozic@gmail.com> wrote:
>>
>> I guess Joe Armstrong (of Erlang fame) would have to say a lot about how
>> to
>> deal with failure properly. According to him, and the seemingly 
>> successful
>> Erlang philosophy (which is, "let it crash"), attempts to locally handle
>> errors are exactly the wrong approach. See his very insightful thesis.
>
> Would you please be so kind as to appoint us to the very thesis you have 
> in
> mind?

Sorry, yes. You can find it on his homepage:

http://www.sics.se/~joe/thesis/armstrong_thesis_2003.pdf

- Andreas

Re: [Caml-list] Today's inflamatory opinion: exceptions are bad

[Jean-Christophe Filliatre]

Andreas Rossberg writes:
 > 
 > I guess Joe Armstrong (of Erlang fame) would have to say a lot about how to 
 > deal with failure properly. According to him, and the seemingly successful 
 > Erlang philosophy (which is, "let it crash"), attempts to locally handle 
 > errors are exactly the wrong approach. See his very insightful thesis.

This is close to one of the rules related to errors in 
Kernighan & Pike's excellent book "The practice of programming"
(http://cm.bell-labs.com/cm/cs/tpop/), which is

  # Detect errors at a low level, handle them at a high level.

I always try to follow this rule and it appears to be a very good one.
And regarding exceptions specifically, another of their rules is
this one:

  # Use exceptions only for exceptional situations. 

-- 
Jean-Christophe

Re: [Caml-list] Today's inflamatory opinion: exceptions are bad

[Richard Jones]

On Sat, Dec 09, 2006 at 10:35:56PM -0500, Chris King wrote:
> One thing Java (sort of) gets right is keeping track of which
> exceptions a function can throw, making it easy to ensure that some
> deeply nested piece of code won't cause the entire application to die
> from some obscure exception.  I'd love to see a similar feature in
> O'Caml, whereby the exceptions which a function can raise are part of
> its type and are inferred and checked by the compiler.

Oh please no!  Checked exceptions are the dumbest and most frustrating
feature of Java (and that's saying something - the Java language has
far more frustrations than most programming languages).

Rich.

-- 
Richard Jones, CTO Merjis Ltd.
Merjis - web marketing and technology - http://merjis.com
Internet Marketing and AdWords courses - http://merjis.com/courses - NEW!
Merjis blog - http://blog.merjis.com - NEW!

Re: [Caml-list] Today's inflamatory opinion: exceptions are bad

[Serge Aleynikov]

Andreas Rossberg wrote:
> "Brian Hurt" <bhurt@spnz.org> wrote:
>>
>> For the former, returning a variant type ('a option if nothing else) 
>> is a better idea, for (at least) two reasons.  One, the type system 
>> enforces the requirement to actually handle the error, at the location 
>> the return value of the function is desired.  Want the result?  Handle 
>> the errors.
> 
> I guess Joe Armstrong (of Erlang fame) would have to say a lot about how 
> to deal with failure properly. According to him, and the seemingly 
> successful Erlang philosophy (which is, "let it crash"), attempts to 
> locally handle errors are exactly the wrong approach. See his very 
> insightful thesis.

This philosophy indeed works quite well in case of Erlang because of its 
good error isolation and concurrency model.

http://www.erlang.se/doc/programming_rules.shtml#REF42466

In that model the worse that can happen to a faulty code is that an 
unhandled exception can crash a light-weight process running that code 
inside a virtual machine.  The death of such a process would be detected 
by a supervising process that would take care of error logging by 
providing essential details about the exception (such as stack frames, 
location and reason of the original fault), and restarting the offending 
process per its configuration spec.

This approach requires very tight cooperation between the run-time 
system and the user process causing a fault.  Since OCaml/C++/Java/etc 
languages don't have native support of concurrency at the language level 
(i.e. rely of the OS for that) this makes it quite difficult to follow 
the "let it crash" philosophy.  The only option in their run-time 
environment for handling uncaught exceptions is to signal OS of an 
abnormal exit, and let the OS do the process cleanup with minimal crash 
information being available at that level.

Brian Hurt wrote:
 > I think I've come to the conclusion that exceptions are bad.

In programming large systems, a very useful rule that I find applicable 
to the subject is summarized here (this thread originated from a very 
similar argument of exceptions vs. tagged tuples, or variant types in 
case of OCaml):

http://www.erlang.org/pipermail/erlang-questions/2006-November/023983.html

Regards,

Serge

Re: [Caml-list] Today's inflamatory opinion: exceptions are bad

[brogoff]

On Sun, 10 Dec 2006, Jon Harrop wrote:
> This has been done. There was a tool called ocamlexc that did whole-program
> analysis to find out which exceptions could propagate where. However, it
> wasn't useful enough to be kept up to date.

I think the fact is that it was never part of the main distribution, and
quickly became out of date. That it wasn't or wouldn't have been useful
is a conclusion that you've drawn which is arguable.

If ocamlexc were part of the distr I'd have it run against all the
programs I build. I'd like the extra checking, but, like Richard Jones,
I don't want to have that in the source code. In all of my Java I use
subclasses of RuntimeException to avoid having to list exceptions.

I'm not convinced by the arguments so far, or even that exceptions are
only for exceptional situations. Is End_of_file really exceptional?
What's the proposed alternative to End_of_file, wrapping results in
option?

-- Brian

Re: [Caml-list] Today's inflamatory opinion: exceptions are bad

[Haoyang Wang]

> And regarding exceptions specifically, another of their rules is
> this one:
>
>   # Use exceptions only for exceptional situations.

For example, when List.find fails to find the item in the list? ;-)
Boxing the result in an option type produces more garbage.

With automatic memory management, there is less need to clean up after
an exception. Thus exceptions can be used quite freely in both Erlang
and o'caml.

ML was designed for theorem provers, and many of its features can be
traced back to that specific purpose. I read somewhere that exception
was introduced in ML for back-tracking, which occurs frequently during
the normal course of trying out various tactics to prove a theorem.

Even today, exceptions are used heavily in coq. Could you comment on
your experiences with the usage of caml exceptions in coq? Are
exceptions raised there "only for exceptional situations"?

Thanks,

Haoyang Wang

Re: [Caml-list] Today's inflamatory opinion: exceptions are bad

[Jean-Christophe Filliatre]

 > >   # Use exceptions only for exceptional situations.

May be I've been misunderstood in my quote of Kernighan & Pike.
I simply think that there is no need to use exceptions when
"exceptional" cases are as frequent as "normal" ones. As others
already said, using option types is a good alternative. And the
efficiency is similar (it happens that I recently made a benchmark on
this particular point and I found out equivalent timings).

 > Even today, exceptions are used heavily in coq. Could you comment on
 > your experiences with the usage of caml exceptions in coq? Are
 > exceptions raised there "only for exceptional situations"?

The Coq proof assistant has been developed by many people and I only
contributed to a small part of it (mostly in the kernel). For this
part, at least, it is indeed true that exceptions are used only for
exceptional situations, mostly to signal typing errors. They are then
handled globally, at the top level of the system.

-- 
Jean-Christophe

Re: [Caml-list] Today's inflamatory opinion: exceptions are bad

[Chris King]

On 12/10/06, Richard Jones <rich@annexia.org> wrote:
> On Sat, Dec 09, 2006 at 10:35:56PM -0500, Chris King wrote:
> > One thing Java (sort of) gets right is keeping track of which
> > exceptions a function can throw, making it easy to ensure that some
> > deeply nested piece of code won't cause the entire application to die
> > from some obscure exception.  I'd love to see a similar feature in
> > O'Caml, whereby the exceptions which a function can raise are part of
> > its type and are inferred and checked by the compiler.
>
> Oh please no!  Checked exceptions are the dumbest and most frustrating
> feature of Java (and that's saying something - the Java language has
> far more frustrations than most programming languages).

I fully agree.  Forcing the programmer to acknowledge the presence of
every possible exception is annoying to write and makes for fragile
code.  Hence I suggested exception inference... no extra effort is
required on the part of the programmer and the code is not made
fragile.  O'Caml provides the safety of checked types without the
hassle of type declarations; in the same way it could provide the
safety of checked exceptions without the hassle of exception
declarations.

- Chris

Re: [Caml-list] Today's inflamatory opinion: exceptions are bad

[Diego Olivier FERNANDEZ PONS]

     Bonjour,

Quoting Haoyang Wang:
> ML was designed for theorem provers, and many of its features can be
> traced back to that specific purpose. I read somewhere that exception
> was introduced in ML for back-tracking, which occurs frequently during
> the normal course of trying out various tactics to prove a theorem.

I heavily use exceptions for backtracking in combinatorial  
optimization (actually it is a combination of exception raising and  
lazy values).
Same as for theorem provers, when a branch is proved sub-optimal it is  
abandoned.

> With automatic memory management, there is less need to clean up after
> an exception. Thus exceptions can be used quite freely in both Erlang
> and o'caml.

The exception based backtracking can be coupled with a garbage  
collector that on backtrack only moves the current pointer back (the  
abandoned memory is just overwritten by the subsequent computations).  
This is traditional in high performance combinatorial optimization  
languages/frameworks/engines.

Quoting Brian Hurt:
> I think I've come to the conclusion that exceptions are bad.
> In Ocaml, they're useless in many cases, and in most cases wrong.

I believe you have only shown that IO in the standard library has a  
poor design and that [try ... with] may be a bit too simple to handle  
all the useful cases (confer to Martin Jambon's extension). I  
completely agree for both points.

> There's one other use for exceptions I've seen (and done)- using them as
> non-local longjmps.  A classic example for this is a delete functions on a
> tree structure- you recurse all the way down to the leafs and discover that
> you're not deleting anything at all, what do you do?  I sometimes  
> (too often) throw an exception to jump out of the recursion back up  
> to the
> top level.

Apart from performance (because of the garbage collector being less  
stressed) that idioma has a few good properties like ensuring that two  
physically different versions of your tree are structurally different.  
In this specific case it only works at depth one (you can add the  
element back and end with two physically different trees that are  
structurally equal). But the technique is usefull for limiting memory  
consumption, ensuring uniqueness or implementing hash-consing and  
related.

       Diego Olivier

Re: [Caml-list] Today's inflamatory opinion: exceptions are bad

[Richard Jones]

On Sun, Dec 10, 2006 at 06:27:37PM -0500, Chris King wrote:
> On 12/10/06, Richard Jones <rich@annexia.org> wrote:
> >On Sat, Dec 09, 2006 at 10:35:56PM -0500, Chris King wrote:
> >> One thing Java (sort of) gets right is keeping track of which
> >> exceptions a function can throw, making it easy to ensure that some
> >> deeply nested piece of code won't cause the entire application to die
> >> from some obscure exception.  I'd love to see a similar feature in
> >> O'Caml, whereby the exceptions which a function can raise are part of
> >> its type and are inferred and checked by the compiler.
> >
> >Oh please no!  Checked exceptions are the dumbest and most frustrating
> >feature of Java (and that's saying something - the Java language has
> >far more frustrations than most programming languages).

I'll moderate what I said before by adding that I now think there are
some exceptions which should never be ignored - for example, it seems
like it's always a mistake to ignore Not_found or End_of_file.  On the
other hand I would almost always want to ignore Sys_error, or else
catch it far away from its point of origin in a wrapper around the
whole program or an event handler.

Perhaps though this is an argument that List.find and friends should
be returning 'a option, not an argument for all exceptions being bad.

> I fully agree.  Forcing the programmer to acknowledge the presence of
> every possible exception is annoying to write and makes for fragile
> code.  Hence I suggested exception inference... no extra effort is
> required on the part of the programmer and the code is not made
> fragile.  O'Caml provides the safety of checked types without the
> hassle of type declarations; in the same way it could provide the
> safety of checked exceptions without the hassle of exception
> declarations.

Agreed.  I'd like to see a detailed prototype.

Rich.

-- 
Richard Jones, CTO Merjis Ltd.
Merjis - web marketing and technology - http://merjis.com
Internet Marketing and AdWords courses - http://merjis.com/courses - NEW!
Merjis blog - http://blog.merjis.com - NEW!

Re: [Caml-list] Today's inflamatory opinion: exceptions are bad

[Mike Lin]

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

Reasonable people can certainly dislike checked exceptions, but if you're
against them, then you should at least demand that your goddamned runtime
system tell you where exceptions are coming from. Is Markus Mottl's patch
making OCaml 3.10? Bueller? Bueller?

On 12/10/06, Richard Jones <rich@annexia.org> wrote:
>
> On Sat, Dec 09, 2006 at 10:35:56PM -0500, Chris King wrote:
> > One thing Java (sort of) gets right is keeping track of which
> > exceptions a function can throw, making it easy to ensure that some
> > deeply nested piece of code won't cause the entire application to die
> > from some obscure exception.  I'd love to see a similar feature in
> > O'Caml, whereby the exceptions which a function can raise are part of
> > its type and are inferred and checked by the compiler.
>
> Oh please no!  Checked exceptions are the dumbest and most frustrating
> feature of Java (and that's saying something - the Java language has
> far more frustrations than most programming languages).
>
> Rich.
>
> --
> Richard Jones, CTO Merjis Ltd.
> Merjis - web marketing and technology - http://merjis.com
> Internet Marketing and AdWords courses - http://merjis.com/courses - NEW!
> Merjis blog - http://blog.merjis.com - NEW!
>
> _______________________________________________
> 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: Type: text/html, Size: 2209 bytes --]

Re: [Caml-list] Today's inflamatory opinion: exceptions are bad

[Richard Jones]

On Mon, Dec 11, 2006 at 12:28:05PM -0500, Mike Lin wrote:
> Reasonable people can certainly dislike checked exceptions, but if you're
> against them, then you should at least demand that your goddamned runtime
> system tell you where exceptions are coming from. Is Markus Mottl's patch
> making OCaml 3.10? Bueller? Bueller?

Don't get me wrong, I think it's a huge shortcoming of the OCaml
runtime that you can't get a stack trace from an exception.  Possibly
second only to the lack of a 'return' statement ...

Rich.

-- 
Richard Jones, CTO Merjis Ltd.
Merjis - web marketing and technology - http://merjis.com
Internet Marketing and AdWords courses - http://merjis.com/courses - NEW!
Merjis blog - http://blog.merjis.com - NEW!

Re: [Caml-list] Today's inflamatory opinion: exceptions are bad

[Olivier Andrieu]

 Chris King [Saturday 9 December 2006] :
 >
 > On 12/9/06, Brian Hurt <bhurt@spnz.org> wrote:
 > > The second reason is that match ... with doesn't break tail recursion,
 > > while try ... with does.  This code is not tail recursive:
 > >
 > > let rec echo_file channel =
 > >        try
 > >                begin
 > >                        let line = input_line channel in
 > >                        print_string (line ^ "\n");
 > >                        echo_file channel
 > >                end
 > >        with
 > >                | End_of_file -> ()
 > > ;;
 > 
 > I'm a big fan of Martin Jambon's "let try" syntax extension [1].  With
 > it the above construct can be written as:
 > 
 > let rec echo_file channel =
 >     let try line = input_line channel in
 >     print_string (line ^ "\n");
 >     echo_file channel
 >     with End_of_file -> ()
 > 
 > and would be tail-recursive.  More often than not this is how I want
 > to write my exception handlers.

I have a syntax extension with a somehow similar syntax, this example
would written like that:
,----
| let rec echo_file channel =
|   catch input_line channel with 
|   | exception End_of_file ->
|       ()
|   | val line ->
|       print_string (line ^ "\n") ;
|       echo_file channel
`----
the tail-recursion is a bit more apparent this way.

-- 
   Olivier

Re: [Caml-list] Today's inflamatory opinion: exceptions are bad

[Frédéric Gava]

----- Original Message -----
From: "Richard Jones" <rich@annexia.org>
To: "Chris King" <colanderman@gmail.com>
Cc: <caml-list@inria.fr>
Sent: Monday, December 11, 2006 4:55 PM
Subject: Re: [Caml-list] Today's inflamatory opinion: exceptions are bad

>Perhaps though this is an argument that List.find and friends should
>be returning 'a option, not an argument for all exceptions being bad.

Hi all,

There is also many case where exceptions are faster than 'a option.

Could you imagine a program where (/) returns 'int option because 1/0 is
impossible ? Could you benchmark serioulsy a OCaml matrix multiplication
again C where Array.get return 'a option and that you have all the time to
match the result ?

Exceptions are goods for performance, easy to manipulate (except in
tail-recursive functions) and understand. Return all the time 'a option
thinks to me C programs where functions return 1 if it has been well
computed or 0 otherwise (you all the time checked if it is 0 or 1 but with
execption you just write try ... with on the block of functions).

The case of Coq is another thinks because you can restric the cases using
high level specification (and in this case, when you extract the proof in
ocaml code you have "assert false"...an exception...arg.)

Frédéric Gava

Re: Ocaml checked exceptions

[Chris King]

On 12/18/06, Bruno De Fraine <Bruno.De.Fraine@vub.ac.be> wrote:
> I think support in the type system for exceptions would look a lot
> like that for polymorphic variants. You can do some of the things you
> suggest with them, but there are some important shortcomings (other
> than the obvious issue that an exception aborts the normal control
> flow and moves up the stack until it is handled).

Agreed, I wonder if a proof-of-concept syntax extension could be
written to take advantage of this similarity?  (Of course its
performance would be abysmal! but it would be a good way to try such a
system in a larger project.)

> > val List.iter: ('a -> unit raises 'b) -> 'a list -> unit raises 'b
>
> val iter : ('a -> ([> `Val of unit ] as 'b)) -> 'a list -> 'b = <fun>
>
> This is a bit different from how you describe the type, but in
> principle I can agree: "iter will have the same return type as the
> argument function; this should include a normal unit value".

Yes, this type seems to fit well.

> > val catch_failures: ('a -> 'b raises [Failure of string | 'c]) -> 'a
> > -> 'b raises 'c
>
> val catch_failures :
>    ('a -> ([> `Failure of string | `Val of 'c ] as 'b)) -> 'a -> 'c -
>  > 'b =
>    <fun>
>
> It is problematic that the final return type will be the same as that
> from the argument. I.e. the exception that we catch is not removed:

OcamlExc (http://caml.inria.fr/pub/old_caml_site/ocamlexc/ocamlexc.htm)
seems to make some headway into this problem by doing flow analysis...
whether it can handle this specific case I'm not sure but I wouldn't
be surprised.

I also know of no way to express this using variants.  Although we
could say something like

val catch_failures : ('a -> ([> `Failure of string | `Val of 'c |
everything_else ] as 'b)) -> 'a -> 'c -> everything_else

and replace the default match case with a case matching [>
everything_else], there's currently no way (that I know of) to create
the "everything_else" type abbreviation, short of enumerating all
known exceptions manually.

- Chris