English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
how to set breakpoint at exception throw?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2000-07-02 (17:10)
From: Gerd Stolpmann <gerd@g...>
Subject: Re: how to set breakpoint at exception throw?
On Fri, 30 Jun 2000, Xavier Leroy wrote:
>> [Scott McPeak:] In the debugger, I'd like to put a breakpoint essentially in
>> the 'raise' function.  The idea is to get control whenever an exception is
>> raised, and be able to take a backtrace.
>> Any ideas on how to do this?
>Reverse execution is your friend: simply run the program under the
>debugger; if an uncaught exception causes the program to terminate,
>back-step (command "back") once, and voila, you're at the point where
>the exception was raised, and you can examine the backtrace.
>If your program traps all exceptions or performs finalization before
>re-raising exceptions, you may have to back-step several times, but
>eventually you'll hit the point where the exception was raised.

This debugging technique should be mentioned in the manual; it is important

Does reverse execution also work for programs doing I/O, for example reading
from a pipe?

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.

For me, such a feature would be more worth than the loss of execution
performance of exceptions. I can imagine that it might be even possible to turn
such a feature dynamically on or off (by setting a hook in the bytecode

For multi-threaded programs, it is sufficient to store the list of uncaught
exceptions for every thread, and to output the list of the failing thread.

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