Re: Where did the exception occur?

Re: Where did the exception occur?

[Damien Doligez]

>From: "David McClain" <dmcclain@azstarnet.com>

>I found that the location of the exception is rarely the source of
>a problem...

Indeed, this discussion started because of an uncaught "Not_found".
Most likely, this is raised by Hashtbl.find, List.assoc, or
String.index (there are a few other).  Knowing exactly which one is
unlikely to help very much.

I don't like the idea of adding run-time information just for the case
when you cannot run the debugger, especially if it incurs a lot of
overhead.  IMO, it would be more interesting to make the debugger work
for embedded code.

In the short term, static analysis seems to be the way to go.

-- Damien

RE: Where did the exception occur?

[Mattias Waldau]

Static analysis wouldn't have help me in my case, since I know that I can
get
Not_found in 10 different places.

Of cource, I could catch each of these at their location, and raise a
specific exception for each.

This, however, would mess up the code.

/mattias

-----Original Message-----
From: Pierre.Weis@inria.fr [mailto:Pierre.Weis@inria.fr]On Behalf Of
Damien Doligez
Sent: Tuesday, October 31, 2000 11:14 AM
To: caml-list@inria.fr
Subject: Re: Where did the exception occur?


>From: "David McClain" <dmcclain@azstarnet.com>

>I found that the location of the exception is rarely the source of
>a problem...

Indeed, this discussion started because of an uncaught "Not_found".
Most likely, this is raised by Hashtbl.find, List.assoc, or
String.index (there are a few other).  Knowing exactly which one is
unlikely to help very much.

I don't like the idea of adding run-time information just for the case
when you cannot run the debugger, especially if it incurs a lot of
overhead.  IMO, it would be more interesting to make the debugger work
for embedded code.

In the short term, static analysis seems to be the way to go.

-- Damien

Re: Where did the exception occur?

[CREGUT Pierre FTRD/DTL/LAN]

I do not agree with you Damien

- static analysis is important but will not solve everything
    ocamlexc delivers you the perfect information but only for perfect code. 
    You have to take care of every case to catch every possible exception to 
    make ocamlexc useful. This is necessary for production code but is 
    tedious for prototyping. These are two different uses of ocaml.

- the debugger is heavy, most of the time the only thing you want is a
  backtrace of your stack as with most debuggers for most languages.
    could it be possible that you do not need to do anything when you
    raise the exception to get a stack dump ? After all, if it is uncaught, 
    nobody should have overwritten the stack between the time where the 
    exception was raised and the time where it is caught by the toplevel
    except may be the stack pointer itself that should be saved.

Another point is that exceptions as a syntaxic construct are still the dark 
side of the language, we lack constructs to express efficiently the way 
we want to deal with them :

      let x = B1 in B2
      f B1 B2

How to catch exceptions raised in B1 but not the one raised in B2 ?
Yes sure you can go back to sum types (note for jocaml users : the problem
is definitely worse with parallelism and replies).
We also need some kind of abbreviation for try ... with EX -> assert false 
for use with ocamlexc

If error handling clutters your code then this code becomes unreadable.
If you do not deal with error handling then you will have unsecure code.

Pierre Crégut

-- 
Pierre Cregut - pierre.cregut@rd.francetelecom.fr - +33 2 96 05 16 28
FTR&D - DTL/MSV - 2 avenue Pierre Marzin - 22307 Lannion Cedex - France

Re: Where did the exception occur?

[Pierre Weis]

> Static analysis wouldn't have help me in my case, since I know that I can
> get Not_found in 10 different places.
> 
> Of cource, I could catch each of these at their location, and raise a
> specific exception for each.
> 
> This, however, would mess up the code.
> 
> /mattias

In those 10 places add 2 lines:

try ...
with Not_found -> assert false

where ... is the old code.

You will obtain exactly the behaviour you want: the file and line will
be reported by the runtime system.

(Joking) Furthermore, your boss will be proud of you since the program will be
10 lines longer (Joking).

Best regards,

Pierre Weis

INRIA, Projet Cristal, Pierre.Weis@inria.fr, http://cristal.inria.fr/~weis/

Where did the exception occur? with Not_found -> assert false

[Mattias Waldau]

Nice idea with 'with Not_found -> assert false'.

1. But why can't the assert-information be available for all raise? wouldn't
that be the same?

2. If the we cannot include this in 'raise', how can I automate it, so that
I get the assert-behaviour if I keep the asserts, and the normal behaviour
otherwise. I normally don't deliver code with assert enabled.

/mattias

Assert

[Ohad Rodeh]

I have a problem with the assert solution. It does not
indicate the line number in the source code. For example, running the
program:

let _ = 
  try 
    raise Not_found
  with _ -> assert false

Results in: 
  Fatal error: uncaught exception Pervasives.Assert_failure("xx.ml", 484,
  496)

	Ohad. 

On Tue, 31 Oct 2000, Mattias Waldau wrote:

> Nice idea with 'with Not_found -> assert false'.
> 
> 1. But why can't the assert-information be available for all raise? wouldn't
> that be the same?
> 
> 2. If the we cannot include this in 'raise', how can I automate it, so that
> I get the assert-behaviourif I keep the asserts, and the normal behaviour
> otherwise. I normally don't deliver code with assert enabled.
> 
> /mattias
> 
> 

Re: Assert

[Nicolas barnier]

Ohad Rodeh wrote:
> 
> I have a problem with the assert solution. It does not
> indicate the line number in the source code. For example, running the
> program:
>
>   Fatal error: uncaught exception Pervasives.Assert_failure("xx.ml", 484,
>   496)

>From the users manual :

exception Assert_failure of (string * int * int)

     Exception raised when an assertion fails. The arguments are the
location of 
the pattern-matching in the source code (file name, position of first
character,
						    ^^^^^^^^^^^^^^^^^^^^^^^^^^^
position of last character).
^^^^^^^^^^^^^^^^^^^^^^^^^^

-- Nicolas

Re: Assert

[John Max Skaller]

Nicolas barnier wrote:
> 
> Ohad Rodeh wrote:
> >
> > I have a problem with the assert solution. It does not
> > indicate the line number in the source code. For example, running the
> > program:
> >
> >   Fatal error: uncaught exception Pervasives.Assert_failure("xx.ml", 484,
> >   496)
> 
> >From the users manual :
> 
> exception Assert_failure of (string * int * int)
> 
>      Exception raised when an assertion fails. The arguments are the
> location of
> the pattern-matching in the source code (file name, position of first
> character,
>                                                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^
> position of last character).
> ^^^^^^^^^^^^^^^^^^^^^^^^^^

This information is fairly useless to me. I use 'vi', which has
no way to move to the n'th character of a file: in particular,
n forward movements do not count line end characters. This information
is also not what the compiler reports; namely line/column numbers,
which is much more useful. IMHO.


-- 
John (Max) Skaller, mailto:skaller@maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
checkout Vyper http://Vyper.sourceforge.net
download Interscript http://Interscript.sourceforge.net