[Caml-list] assert caught by try with _

[Caml-list] assert caught by try with _

[Chris Hecker]

Is the the "right thing" for assert to be caught by a try ... with _ -> ... 
block?  In other words, it seems like you want an assert to always blow up 
if asserts are turned on, not to fail silently when there's a try block 
somewhere higher up in the program.  Maybe it should be an option to have 
it fail immediately regardless of whether there's an exception handler 
around it?  The problem is that the workaround is to muck with every "with" 
expression to ensure you don't accidentally catch an assert, which is a 
huge pain and error prone, so it seems easier to have an option to just 
blow up.  The rationale is that asserts are meta, not part of the main 
program's flow.

I just got bitten by this and spent a couple hours trying to figure out why 
my program silently stopped working.

Thanks,
Chris

# let _ = try assert false with _ -> ();;
- : unit = ()

-------------------
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] assert caught by try with _

[Nicolas Cannasse]

> Is the the "right thing" for assert to be caught by a try ... with _ ->
...
> block?  In other words, it seems like you want an assert to always blow up
> if asserts are turned on, not to fail silently when there's a try block
> somewhere higher up in the program.  Maybe it should be an option to have
> it fail immediately regardless of whether there's an exception handler
> around it?  The problem is that the workaround is to muck with every
"with"
> expression to ensure you don't accidentally catch an assert, which is a
> huge pain and error prone, so it seems easier to have an option to just
> blow up.  The rationale is that asserts are meta, not part of the main
> program's flow.

You could tell the same for stack overflow and some other kinds of
exceptions. OCaml uniformly treat failures as exceptions, and that's the
right thing to do. But catching exceptions with _ , without even printing
them, is not the "right thing" and is definitly huge pain and error prone.

Nicolas Cannasse

-------------------
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] assert caught by try with _

[Chris Hecker]

>You could tell the same for stack overflow and some other kinds of
>exceptions. OCaml uniformly treat failures as exceptions, and that's the
>right thing to do. But catching exceptions with _ , without even printing
>them, is not the "right thing" and is definitly huge pain and error prone.

I totally disagree about assert being the same as a stack overflow in 
nature, but more importantly, you're ignoring the lessons learned from C++ 
and Java on the exception specification front.  You just don't know what 
exceptions code you call in a real program will throw in general.  There 
are plenty of times when you want to try something at runtime and just bail 
if it doesn't work, and you don't care about the specifics of why it didn't 
work.  A single "with _" will mask any assertions living below it, which 
seems to me to be a bad thing since by definition an assert is a 
development debugging tool.  Assert should just blow up, like in C (at 
least as an option).  You shouldn't have to remember to put a "with" clause 
in for it.

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] assert caught by try with _

[Jacques Garrigue]

From: Chris Hecker <checker@d6.com>

> >You could tell the same for stack overflow and some other kinds of
> >exceptions. OCaml uniformly treat failures as exceptions, and that's the
> >right thing to do. But catching exceptions with _ , without even printing
> >them, is not the "right thing" and is definitly huge pain and error prone.
> 
> I totally disagree about assert being the same as a stack overflow in 
> nature, but more importantly, you're ignoring the lessons learned from C++ 
> and Java on the exception specification front.  You just don't know what 
> exceptions code you call in a real program will throw in general.  There 
> are plenty of times when you want to try something at runtime and just bail 
> if it doesn't work, and you don't care about the specifics of why it didn't 
> work.  A single "with _" will mask any assertions living below it, which 
> seems to me to be a bad thing since by definition an assert is a 
> development debugging tool.  Assert should just blow up, like in C (at 
> least as an option).  You shouldn't have to remember to put a "with" clause 
> in for it.

But you might really want to catch assert failures!
For instance if you're building a debugging tool.
So the problem rather stems from the fact exn is a flat type. You have
no way to specify "categories" of exceptions, like you would do in
Java.
Also you could view the behaviour of [try ... with _ -> ...] as
dangerous, and prefer a different behaviour. Unfortunately, _ is
expected to mean any exception, and it would be difficult to make it
mean something else.

Note that it's easy enough to define a class of exceptions as fatal:

let check_fatal = function
    Assert_failure _ | Stack_overflow | Match_failure _ as exn -> raise exn
  | _ -> ();;

Then you just have to write

  try ... with exn -> check_fatal exn; ...

You can certainly use camlp4 to do this automatically.

Alternatively, one could argue that this is similar to the ctrl-break
problem: [Sys.catch_break] allows you to decide whether you want it to
be catchable or not. Unfortunately this would imply some extra cost
for [raise].

    Jacques

-------------------
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] assert caught by try with _

[Chris Hecker]

>But you might really want to catch assert failures!
>For instance if you're building a debugging tool.

Okay, but it seems like a compile time switch would serve both 
interests.  Plus, it seems like the "assert should blow up" usage would be 
far more common, since the number of people writing non-debugging-tool code 
is far larger than the number writing debugging tool code.

Another way of thinking about this is that almost everybody re-#defines 
assert in production C/C++ programs to do their own assert handling during 
development (whether it's printing out additional information, allowing you 
to drop into the debugger, popping up a message box, sending bug email, 
whatever).  With assert hard-coded into ocaml, you can't do this.  I could 
use a different function than assert, but then it won't compile out, 
etc.  I could use camlp4 to make my own assert, but then I take a 
compilation speed hit on all my files, etc.

Anyway, it sounds like this behavior isn't surprising to anybody else, so 
I'll add it to the list of things that only I think are broken about ocaml.  :)

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] assert caught by try with _

[Yaron M. Minsky]

On Tue, 2003-07-29 at 17:01, Chris Hecker wrote:
> >But you might really want to catch assert failures!
> >For instance if you're building a debugging tool.
> 
> Okay, but it seems like a compile time switch would serve both 
> interests.  Plus, it seems like the "assert should blow up" usage would be 
> far more common, since the number of people writing non-debugging-tool code 
> is far larger than the number writing debugging tool code.
> 
> Another way of thinking about this is that almost everybody re-#defines 
> assert in production C/C++ programs to do their own assert handling during 
> development (whether it's printing out additional information, allowing you 
> to drop into the debugger, popping up a message box, sending bug email, 
> whatever).  With assert hard-coded into ocaml, you can't do this.  I could 
> use a different function than assert, but then it won't compile out, 
> etc.  I could use camlp4 to make my own assert, but then I take a 
> compilation speed hit on all my files, etc.
> 
> Anyway, it sounds like this behavior isn't surprising to anybody else, so 
> I'll add it to the list of things that only I think are broken about ocaml.  :)

Not so fast.  I have hit the same issue and entirely agree.  In general,
the issue of making sure that an exception escapes when you want it to
is a bit of a problem, and it would be nice to have some way of dealing
with this, and not just with asserts.  But certainly asserts should have
the option for the kind of always-die behavior you're talking about.

y

-- 
|--------/            Yaron M. Minsky              \--------|
|--------\ http://www.cs.cornell.edu/home/yminsky/ /--------|

Open PGP --- KeyID B1FFD916 (new key as of Dec 4th)
Fingerprint: 5BF6 83E1 0CE3 1043 95D8 F8D5 9F12 B3A9 B1FF D916



-------------------
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] assert caught by try with _

[james woodyatt]

On Wednesday, Jul 30, 2003, at 03:22 US/Pacific, Yaron M. Minsky wrote:
>
> Not so fast.  I have hit the same issue and entirely agree.  In 
> general,
> the issue of making sure that an exception escapes when you want it to
> is a bit of a problem, and it would be nice to have some way of dealing
> with this, and not just with asserts.  But certainly asserts should 
> have
> the option for the kind of always-die behavior you're talking about.

let die_unless p s =
	if not p then begin
		Printf.printf "die: %s\n" s;
		flush stdout;
		exit (-1)
	end

Slightly less convenient than assert, but has the effect of dying 
immediately.

For my part, I *like* the behavior of assert and exception the way it 
is.


-- 
j h woodyatt <jhw@wetware.com>

-------------------
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] assert caught by try with _

[Michal Moskal]

On Tue, Jul 29, 2003 at 02:01:07PM -0700, Chris Hecker wrote:
> Another way of thinking about this is that almost everybody re-#defines 
> assert in production C/C++ programs to do their own assert handling during 
> development (whether it's printing out additional information, allowing you 
> to drop into the debugger, popping up a message box, sending bug email, 
> whatever).  With assert hard-coded into ocaml, you can't do this.  

try
  main ()
with Assert_failure (line, col, file) -> (* or whatever it is *)
  prerr_endline "Panic! Contact support"

-- 
: Michal Moskal :: http://www.kernel.pl/~malekith : GCS {C,UL}++++$ a? !tv
: When in doubt, use brute force. -- Ken Thompson : {E-,w}-- {b++,e}>+++ h

-------------------
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] assert caught by try with _

[William Lovas]

On Wed, Aug 06, 2003 at 02:19:41PM +0200, Michal Moskal wrote:
> On Tue, Jul 29, 2003 at 02:01:07PM -0700, Chris Hecker wrote:
> > Another way of thinking about this is that almost everybody re-#defines 
> > assert in production C/C++ programs to do their own assert handling during 
> > development (whether it's printing out additional information, allowing you 
> > to drop into the debugger, popping up a message box, sending bug email, 
> > whatever).  With assert hard-coded into ocaml, you can't do this.  
> 
> try
>   main ()
> with Assert_failure (line, col, file) -> (* or whatever it is *)
>   prerr_endline "Panic! Contact support"

This won't trigger, though, if the exception has already been caught
upstream.

William

-------------------
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] assert caught by try with _

[Michal Moskal]

On Wed, Aug 06, 2003 at 10:50:21AM -0400, William Lovas wrote:
> On Wed, Aug 06, 2003 at 02:19:41PM +0200, Michal Moskal wrote:
> > On Tue, Jul 29, 2003 at 02:01:07PM -0700, Chris Hecker wrote:
> > > Another way of thinking about this is that almost everybody re-#defines 
> > > assert in production C/C++ programs to do their own assert handling during 
> > > development (whether it's printing out additional information, allowing you 
> > > to drop into the debugger, popping up a message box, sending bug email, 
> > > whatever).  With assert hard-coded into ocaml, you can't do this.  
> > 
> > try
> >   main ()
> > with Assert_failure (line, col, file) -> (* or whatever it is *)
> >   prerr_endline "Panic! Contact support"
> 
> This won't trigger, though, if the exception has already been caught
> upstream.

Of course, that's what's wrong with [try ... with _ -> ...]. What I
wanted to show is, that treating assert as an exception makes it
possible to customize it (with standard features of the language).

-- 
: Michal Moskal :: http://www.kernel.pl/~malekith : GCS {C,UL}++++$ a? !tv
: When in doubt, use brute force. -- Ken Thompson : {E-,w}-- {b++,e}>+++ h

-------------------
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] assert caught by try with _

[Jason Hickey]

Chris Hecker wrote:
> Is the the "right thing" for assert to be caught by a try ... with _ -> 
> ... block?

I don't know.  It seems reasonable to have exceptional conditions caught 
by the exception handler...

However, it may be reasonable to ask for more than one exception 
type--it seems like poor software engineering to statically list *all* 
the possible reasonable exceptions in a try/with block, except for 
Assert_failure.  This idea will fail as new exceptions are added.

To help avoid this problem, in our work we generally declare a type of 
application errors (not the exact syntax but close enough):

    type application_error =
       NoClue
     | BadIdea of string
     | IWouldIfICouldButICantSoIWont
     | ...

    exception ApplicationError of application_error

All raises are of the form (raise (ApplicationError ...)), and the 
"default" exception handler is (try ... with ApplicationError _ -> ...). 
  This idea works ok, but is not scalable.

Jason

-- 
Jason Hickey                  http://www.cs.caltech.edu/~jyh
Caltech Computer Science      Tel: 626-395-6568 FAX: 626-792-4257

-------------------
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] unwind-protect

[Jason Hickey]

A related, but pragmatic problem.  Suppose we have some imperative code, 
and we need an "unwind-protect" operation.  Consider this code to make 
sure a file is closed after it is used.

let with_open_file (name : string) (f : in_channel -> unit) =
    let inc = open_in name in
       try
          f inc;
          close inc
       with
          exn ->
             close inc;
             raise exn

1. It would be wonderful to have a "finally" clause, so we don't have to 
duplicate the close operation.  I suppose we can fake it with CamlP4, 
but it seems better built-in.

2. This kind of exception re-raising does not work well with stack 
tracing (OCAMLRUNPARAM=b).  It would be very nice to add a "finally" 
clause that did not interfere with stack tracing, or make it so that 
re-raising would preserve the location where the exception was created.

Jason

-- 
Jason Hickey                  http://www.cs.caltech.edu/~jyh
Caltech Computer Science      Tel: 626-395-6568 FAX: 626-792-4257

-------------------
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] unwind-protect

[Yaron M. Minsky]

I've more or less given up on this feature ever finding it's way into
the language, and I ended up writing my own, like many others.  One of
the downsides of having people write their own unwind-protect's is that
it's a tad tricky to get right.  The trick is ensuring that the cleanup
code only gets run once, even if an exception is thrown in the middle of
the cleanup.  Here's my shot at it.

        let protect ~f ~(finally: unit -> unit) =
          let result = ref None in
          try
            result := Some (f ());
            raise Exit
          with
              Exit as e ->
                finally ();
                (match !result with Some x -> x | None -> raise e)
            | e ->
                finally (); raise e

I definitely agree it would be nice to have this kind of thing in the
language, or at least in the standard library.  When we give newbies
examples of how to read a file, giving them an example that uses
unwind-protect would prevent many future file-descriptor-exhaustion
bugs.

y

On Wed, 2003-07-30 at 01:44, Jason Hickey wrote:
> A related, but pragmatic problem.  Suppose we have some imperative code, 
> and we need an "unwind-protect" operation.  Consider this code to make 
> sure a file is closed after it is used.
> 
> let with_open_file (name : string) (f : in_channel -> unit) =
>     let inc = open_in name in
>        try
>           f inc;
>           close inc
>        with
>           exn ->
>              close inc;
>              raise exn
> 
> 1. It would be wonderful to have a "finally" clause, so we don't have to 
> duplicate the close operation.  I suppose we can fake it with CamlP4, 
> but it seems better built-in.
> 
> 2. This kind of exception re-raising does not work well with stack 
> tracing (OCAMLRUNPARAM=b).  It would be very nice to add a "finally" 
> clause that did not interfere with stack tracing, or make it so that 
> re-raising would preserve the location where the exception was created.
> 
> Jason
-- 
|--------/            Yaron M. Minsky              \--------|
|--------\ http://www.cs.cornell.edu/home/yminsky/ /--------|

Open PGP --- KeyID B1FFD916 (new key as of Dec 4th)
Fingerprint: 5BF6 83E1 0CE3 1043 95D8 F8D5 9F12 B3A9 B1FF D916



-------------------
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] unwind-protect

[Didier Remy]

> One of the downsides of having people write their own unwind-protect's is
> that it's a tad tricky to get right.  The trick is ensuring that the
> cleanup code only gets run once, even if an exception is thrown in the
> middle of the cleanup.

Yes, this is essential when the finalization code is a parameter.
You do not need to use side effects, though. 

    type 'a computation = Value of 'a | Exception of exn

    let freeze_computation f x =
      try Value (f x) with z -> Exception z 

    let unfreeze_computation = function
        Value v -> v | Exception z -> raise z;;

    let try_finalize f x g y = 
      let fx = freeze_computation f x in
      let _ = g y in 
      unfreeze_computation fx

There is still a choice in the semantics regarding which exception to return
when both computations f x and g y fail. The above code reports the
exception of the finalization code. To report the exception of the
computation, replace

      let _ = g y in
by 

      let _ = freeze_computation g y in

Didier

-------------------
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] unwind-protect

[Jacques Garrigue]

Yet another version which doesn't allocate anything in the heap:

  let protect ~f ~(finally: unit -> unit) =
    let res = try f () with e -> finally (); raise e in
    finally ();
    res

Jacques Garrigue

-------------------
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] unwind-protect

[William Lovas]

On Tue, Jul 29, 2003 at 10:44:58PM -0700, Jason Hickey wrote:
> 2. This kind of exception re-raising does not work well with stack 
> tracing (OCAMLRUNPARAM=b).  It would be very nice to add a "finally" 
> clause that did not interfere with stack tracing, or make it so that 
> re-raising would preserve the location where the exception was created.

It looks to me like re-raising *does* preserve the location where the
exception was created.  My toy example:


--8<-- raise.ml ---
let f () = raise Not_found
--8<---------------

--8<-- main.ml ---
try Raise.f () with e -> raise e
--8<--------------

% ocamlc -g -o go raise.ml go.ml
% ./go
Fatal error: exception Not_found
Raised at module Raise, character 26
Called from module Main, character 14
Re-raised at module Main, character 32


I remember one of the developers mentioning this behavior in a discussion a
while back.

cheers,
William

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