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

Re: Assert

[Xavier Leroy]

> From what I can see from the sources, for every error and warning
> message the whole source file is parsed again with a special
> lexer to determine the line number (parsing/linenum.mll). Could
> anybody comment on this approach to printing error messages? (It
> seems very very very strange to me.)

Well, keeping track of character numbers during lexing is trivial,
while keeping track of line numbers requires a bit more work
(especially with the # lineno construct).  So, the idea was to lex and
parse source files at full speed when there is no error, and pay the
price of computing line numbers only when an error needs to be
reported.

Also, this separates concerns between the two lexers: one deals with
the language proper, the other with line numbers.  Call it
aspect-oriented programming if you wish :-)

This said, it's one of those ideas that look nice at first sight, but
have some practical drawbacks, e.g. no line numbers are printed for
Match_failure and Assert_failure exceptions, and the debugger has
problems coping with # lineno "filename" directives.  We've been
considering going back to a more traditional approach, with line and
column numbers computed during lexing and stored in the abstract
syntax tree.

- Xavier Leroy

Re: Assert

[Hendrik Tews]

Hi,

Xavier Leroy writes:
   From: Xavier Leroy <Xavier.Leroy@inria.fr>
   Date: Fri, 3 Nov 2000 11:37:52 +0100
   Subject: Re: Assert
   
   > List,
   >     I still cannot figure out why the assert instruction
   > does not return the line number at which the exception occures.
   
   Basically, it's because the compiler uses character numbers
   internally; line numbers are computed only when printing an error message.
   
>From what I can see from the sources, for every error and warning
message the whole source file is parsed again with a special
lexer to determine the line number (parsing/linenum.mll). Could
anybody comment on this approach to printing error messages? (It
seems very very very strange to me.)


Besides that I have another suggestion for the 
this discussion thread about escaping assertions:

Would it be possible to reserve a keyword (or a standard library
symbol) "current_line_number" that, by magic, expands to its
location (a tuple or triple of integers) in the source file? This
way the magic of assert would be available for us users, one
could write

try ....
with 
  ...
  | a -> prerr_endline( "Exception " ^ (Printexc.to_string a) ^ 
                        " escaping at " ^ 
                        ( ... current_line_number))


Bye,

Hendrik

Re: Assert

[Stefan Monnier]

>>>>> "Chris" == Chris Hecker <checker@d6.com> writes:
>> Suppose one has a LARGE ocaml file, with several "assert" instructions.
>> When an assert exception occures, it is not an easy task to figure out
>> where it came from.
> M-x goto-char

M-x next-error could also be made to work.


        Stefan

Re: Assert

[Damien Doligez]

>From: Ohad Rodeh <orodeh@cs.huji.ac.il>

>Suppose one has a LARGE ocaml file, with several "assert" instructions. 
>When an assert exception occures, it is not an easy task to figure out
>where it came from. 

Open the file in emacs.  Go to the beginning of the file.  Type
<ESC> <number-of-characters> control-F.  It works even if there are
several assert expressions in the same line.  The compiler doesn't
keep track of the line number, so it cannot include it in the
exception.

-- Damien

Re: Assert

[Xavier Leroy]

> List,
>     I still cannot figure out why the assert instruction
> does not return the line number at which the exception occures.

Basically, it's because the compiler uses character numbers
internally; line numbers are computed only when printing an error message.

> The characters are no good to me in debugging. I suppose they make
> sense from the compiler's point of view, but they are no use to me. 

With Emacs, it's as easy to jump to a character number (M-x goto-char)
than to jump to a line number (M-x goto-line).  Since we (the OCaml
developers) are Emacs fans, we didn't think that character numbers
might be a problem for some users.

- Xavier Leroy

Re: Assert

[Nicolas barnier]

Ohad Rodeh wrote:
> 
> The characters are no good to me in debugging. I suppose they make
> sense from the compiler's point of view, but they are no use to me.

Under Emacs or XEmacs : '->' or C-f move forward one character, and
C-u n repeat a command n times. So C-u n '->' where n is the location
returned by the assert failure and when done at the beginning of the
specified file will point you at the right piece of code.

-- Nicolas

Re: Assert

[Chris Hecker]

>Suppose one has a LARGE ocaml file, with several "assert" instructions. 
>When an assert exception occures, it is not an easy task to figure out
>where it came from. 

M-x goto-char

:)

Chris

Assert

[Ohad Rodeh]

List,
    I still cannot figure out why the assert instruction
does not return the line number at which the exception occures.
The characters are no good to me in debugging. I suppose they make
sense from the compiler's point of view, but they are no use to me. 

Suppose one has a LARGE ocaml file, with several "assert" instructions. 
When an assert exception occures, it is not an easy task to figure out
where it came from. 

  Can someone enlighten me on this point?

	Ohad.