Nick Benton and Andrew Kennedy have addressed this rather under-appreciated deficiency in ML exceptions in their paper "Exceptional Syntax"

http://research.microsoft.com/~akenn/sml/ExceptionalSyntax.pdf

The topic has also been raised here before http://caml.inria.fr/archives/200407/msg00028.html 

I think this is so sensible that it should be adopted in all variants of ML. 

An OCaml or F# version of their construct might be 
  "let try <bindings> 
   in <expr> 
   with <matching>"

Only the bindings are covered by the "try".  e.g.

let readfile chan =
  let rec loop rlst =
    let try line = input_line chan
        in loop (line :: rlst)
        with End_of_file -> List.rev rlst
  in
    loop []

(note: reduces 17 lines to 7)

Another possibility might be 

  "let try <bindings> 
   with <matching>
   in <expr> "

or indeed you could support both of the above, leaving it up to the programmer to choose where to place the ever-awkward handling code. Unfortunately the syntax 

  "try let <bindings> 
   in <expr> 
   with <matching>"

is too ambiguous when iterated "let ... in" bindings are used.

Don


-----Original Message-----
From: caml-list-admin@yquem.inria.fr [mailto:caml-list-admin@yquem.inria.fr] On Behalf Of Nicolas George
Sent: 26 December 2004 14:09
To: Caml mailing list
Subject: Re: [Caml-list] Checking for eof

Le sextidi 6 nivôse, an CCXIII, briand@aracnet.com a écrit :
>       try
>         (input_line chan), false
>       with
>         | End_of_file -> "", true

I would have written that

	try
	  Some (input_line chan)
	with
	  | End_of_file -> None

but the idea is the same. I find it is an irritating limitation of OCaml
syntax to have to pack and then unpack all local values in order to uncatch
exceptions. Something like

	try
	  let line = input_line chan in
	  untry
          loop (line :: rlst)
	with
	  | End_of_file -> List.rev rlst

This syntax is somewhat awkward: untry is neither a third member of the
try...with structure, because it must be inside the flow of let...in
declaration, nor a stand-alone statement, because it must not be allowed
anywhere outside try...with.

On the contrary, as far as I can see, the semantics is quite simple.