From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id XAA06000 for caml-red; Wed, 5 Jul 2000 23:24:50 +0200 (MET DST) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id UAA06296 for ; Tue, 4 Jul 2000 20:59:45 +0200 (MET DST) Received: from mail.ngi.de ([195.243.0.227]) by concorde.inria.fr (8.10.0/8.10.0) with ESMTP id e64IxiH07363; Tue, 4 Jul 2000 20:59:45 +0200 (MET DST) Received: from ice.darmstadt.netsurf.de (62.158.14.117) by mail.ngi.de (5.1.034) id 39451E8100135FCE; Tue, 4 Jul 2000 20:56:10 +0200 Received: from localhost (localhost [[UNIX: localhost]]) by ice.darmstadt.netsurf.de (8.9.3/8.9.3) id UAA06044; Tue, 4 Jul 2000 20:58:42 +0200 From: Gerd Stolpmann Reply-To: gerd@gerd-stolpmann.de Organization: privat To: John Max Skaller , Patrick M Doane Subject: Re: how to set breakpoint at exception throw? Date: Tue, 4 Jul 2000 20:19:20 +0200 X-Mailer: KMail [version 1.0.28] Content-Type: text/plain Cc: Xavier Leroy , Scott McPeak , caml-list@inria.fr References: <3961F7FA.643D7863@maxtal.com.au> In-Reply-To: <3961F7FA.643D7863@maxtal.com.au> MIME-Version: 1.0 Message-Id: <0007042058420E.14914@ice> Content-Transfer-Encoding: 8bit Sender: weis@pauillac.inria.fr 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 ----------------------------------------------------------------------------