line number in exception history?

line number in exception history?

[Eijiro Sumii]

Hi,

(Sorry if this is a FAQ - I searched a little and couldn't find the answer.)

A student in Tokyo (_not_ CS major!) reported a "problem" (see below)
of ocaml in his blog.  I guess it is because the line/character
numbers point to the _head_ of the expression that _follows_ where the
exception went through.  Is this a feature or a bug?

Thanks,

        Eijiro

> cat main.ml
let () =
  let ret = Bar.barFunction (-10) in
  print_int (ret + 100)
> cat foo.ml
let fooFunction x =
  if x > 0 then x - 1
  else raise (invalid_arg "Give me positive!")
> cat bar.ml
let barFunction x =
  let y = x + 1 in
  Foo.fooFunction y
> cat main.ml
let () =
  let ret = Bar.barFunction (-10) in
  print_int (ret + 100)
> cat bar.ml
let barFunction x =
  let y = x + 1 in
  Foo.fooFunction y
> cat foo.ml
let fooFunction x =
  if x > 0 then x - 1
  else raise (invalid_arg "Give me positive!")
> ocamlc -g foo.ml bar.ml main.ml -o test
> env OCAMLRUNPARAM=b ./test
Fatal error: exception Invalid_argument("Give me positive!")
Raised at file "pervasives.ml", line 22, character 17
Re-raised at file "foo.ml", line 3, character 46
Called from file "main.ml", line 3, character 2

Re: line number in exception history?

[Eijiro Sumii]

P.S.  The following variant is even more strange.  (Look at the
"re-raised" line, please.)

> cat foo.ml
let fooFunction x =
  if x > 0 then x - 1
  else raise (invalid_arg "Give me positive!")
> cat bar.ml
let barFunction x =
  let y = x + 1 in
  Foo.fooFunction y
> cat main.ml
let f () = ()

let test () =
  try
    Bar.barFunction (-10)
  with e -> raise e

let g y = y + 1

let () =
  f ();
  let ret = test () in
  print_int (ret + 100)
> ocamlc -g foo.ml bar.ml main.ml -o test
> env OCAMLRUNPARAM=b ./test
Fatal error: exception Invalid_argument("Give me positive!")
Raised at file "pervasives.ml", line 22, character 17
Re-raised at file "foo.ml", line 3, character 46
Called from file "main.ml", line 5, character 25
Re-raised at file "main.ml", line 1, character 11
Called from file "main.ml", line 13, character 2

Re: [Caml-list] line number in exception history?

[Xavier Leroy]

> A student in Tokyo (_not_ CS major!) reported a "problem" (see below)
> of ocaml in his blog.  I guess it is because the line/character
> numbers point to the _head_ of the expression that _follows_ where the
> exception went through.  Is this a feature or a bug?

Your code is strange: you do realize that
     raise (invalid_arg "Give me positive!")
is weird because invalid_arg is a function that raises an exception itself?

Assuming that was intended, the backtrace is indeed slightly
inaccurate in two ways:

> Raised at file "pervasives.ml", line 22, character 17

That is correct.

> Re-raised at file "foo.ml", line 3, character 46

That should be "Called from file" but I guess the enclosing "raise"
confused the backtrace printer.

> Called from file "main.ml", line 3, character 2

This is indeed off by one line.  In general, the location following the
function call is reported, i.e

         function_that_raises arg1 arg2 arg3
                                            ^
                                            reported location

while in your example the following "in \n" is skipped.  Maybe one of
us will look at this, but I don't fell it's a big issue.

- Xavier Leroy

Re: [Caml-list] line number in exception history?

[Eijiro Sumii]

Thanks for your response!

On 10/11/05, Xavier Leroy <Xavier.Leroy@inria.fr> wrote:
> Your code is strange: you do realize that
>      raise (invalid_arg "Give me positive!")
> is weird because invalid_arg is a function that raises an exception itself?

Yes it is, but this was not quite my (or the student's) point...

> This is indeed off by one line.  In general, the location following the
> function call is reported, i.e
>
>          function_that_raises arg1 arg2 arg3
>                                             ^
>                                             reported location
>
> while in your example the following "in \n" is skipped.  Maybe one of
> us will look at this, but I don't fell it's a big issue.

I see, that's just as I guessed.  I agree it's not a big issue.  What
about the second example (in my follow-up message)?

Best,

        Eijiro