Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
From: Gerd Stolpmann <gerd@gerd-stolpmann.de>
To: John Max Skaller <skaller@maxtal.com.au>,
	Patrick M Doane <patrick@watson.org>
Cc: Xavier Leroy <Xavier.Leroy@inria.fr>,
	Scott McPeak <smcpeak@cs.berkeley.edu>,
	caml-list@inria.fr
Subject: Re: how to set breakpoint at exception throw?
Date: Tue, 4 Jul 2000 20:19:20 +0200	[thread overview]
Message-ID: <0007042058420E.14914@ice> (raw)
In-Reply-To: <3961F7FA.643D7863@maxtal.com.au>

On Tue, 04 Jul 2000, John Max Skaller wrote:
>> On Sat, 1 Jul 2000, Gerd Stolpmann wrote:
>> 
>> > Nevertheless, I have a wish: At least for programs compiled with the bytecode
>> > compiler, an automatic backtrace of uncaught exceptions would be often helpful
>> > (i.e I get a list where the last uncaught exception was raised, and all
>> > locations where it is re-raised in the "with" clause of the "try" statement).
>> > First, this type of error is very frequent, and it would save much time if the
>> > location where the problem occurs were output from the failing program itself.
>> > Second, under some environments it is difficult to run the debugger; not every
>> > program is run from the command-line (CGI programs, for example). Furthermore,
>> > such a feature would help bug searching in production environments: on such
>> > machines, there is usually no debugger installed, and it is sometimes difficult
>> > to reconstruct the failing data case.
>
>Hmmmm. I don't know how to do this in ocaml, but in C++ and Python it is
>easy:
>you create an exception one of whose components is the caught exception,
>and throw it, thus preserving the whole exception chain. That is, you
>can do
>this in user space without special system support.

In general, you are right; the problem is that I do not have access to the
location in the source code where the exception happened. I'm interested in the
line number and the file name of the statement that originally caused the
exception. Example:

try 
  try
    raise Not_found
  with
    x ->
      (* XXX: Clean-up code here *)
      raise x
with
  x ->
    (* XXX: Clean-up code here *)
    raise x

which would cause the following backtrace:

Uncaught exception: Not_found
Exception backtrace:
- File x, line 3: Not_found
- File x, line 7: Not_found
- File x, line 11: Not_found

One can imagine having a user space "raise" function:

let exception_list := ref []

let alt_raise exc =
  exception_list := (caller.file_name, caller.line_number, exc) ::
                    !exception_list;
  raise exc

Problems: First, there is no "caller" information available without additional
help of the compiler. Second, I want to reset exception_list whenever the "with"
clause returns a regular result. (The latter is a simplification: only the last
uninterrupted chain of exceptions is reported. I think this is sufficient for
debugging.)

My proposal is to modify the bytecode compiler/interpreter such that every
"raise" bytecode statement has access to the location of the exception, and
that (optionally) the bytecode interpreter adds the exception to the
exception_list, or resets this list (this would require an additional bytecode
statement). This would not change the representation of exceptions, and it
would cost minimal extra execution time (the exception_list could be represented
as array with an upper limit).

I do not suggest to modify the native compiler in the same way, because it
would cost (relatively) much more time than for the bytecode system.

Gerd
-- 
----------------------------------------------------------------------------
Gerd Stolpmann      Telefon: +49 6151 997705 (privat)
Viktoriastr. 100             
64293 Darmstadt     EMail:   gerd@gerd-stolpmann.de
Germany                     
----------------------------------------------------------------------------



  reply	other threads:[~2000-07-05 21:24 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-06-28 23:24 Scott McPeak
2000-06-30 13:08 ` Xavier Leroy
2000-07-01 12:57   ` Gerd Stolpmann
2000-07-03 15:05     ` Patrick M Doane
2000-07-03 21:43       ` Norman Ramsey
2000-07-06  3:05         ` Michael Hohn
2000-07-04 14:43       ` John Max Skaller
2000-07-04 18:19         ` Gerd Stolpmann [this message]
2000-07-05 22:13           ` Jean-Christophe Filliatre
2000-07-06  1:26           ` Max Skaller
2000-07-06 11:23           ` Daniel de Rauglaudre
2000-07-05  1:28   ` Scott McPeak
2000-07-05 21:29 Don Syme

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0007042058420E.14914@ice \
    --to=gerd@gerd-stolpmann.de \
    --cc=Xavier.Leroy@inria.fr \
    --cc=caml-list@inria.fr \
    --cc=patrick@watson.org \
    --cc=skaller@maxtal.com.au \
    --cc=smcpeak@cs.berkeley.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox