Debugger - back step
Hi,
is it possible in Java (and is there a feature proposal) to do step back in
the debugger? That is, the ability to go to the previous line of code when
doing step-by-step debugging for a limited set of instruction (say 10).
If there is, the feature that would completely change my life when debugging
would be the: "Breakpoint 10 lines before an exception is thrown". That is,
the program is executed until an uncatched exception is detected, steps back
10 lines, and starts the step-by-step debugging.
Every time I have an exception, I want to see what is happening some lines
before that. Usually I have to go through all the code, putting breakpoint
in a good place, and sometimes it's very time consuming.
Is there something like it?
Thanks,
Gabriele
# 1
Slashdot.org mentioned some cool debugger. I don't know for sure if it does what you need. It may do so.
Anyway, for you problem, I think you may find out the problem by insert hint a long the way (like System.out.println) and zoom into the error before putting break point, so that you don't take so many run to get there (it's like a binary search, would not take that many println to get there).
vy_ho at 2007-7-2 23:51:22 >
# 2
Gabriele Carcassi wrote:
> is it possible in Java (and is there a feature proposal) to do step back in
> the debugger? That is, the ability to go to the previous line of code when
> doing step-by-step debugging for a limited set of instruction (say 10).
Don't think so. It would be really nice though. I always get impatient
when stepping and go past the line with the problem and have to start over.
But this could be pretty hard to implement. Consider if the Java program
was making native calls (I/O prints, graphic repaints, ...) during this
time period. You can't exactly undo them.
Also I would bet it would be possible with some effort and caveats to
back up a limited number of steps to a previous point where you had set
a breakpoint or stepped to; but backing up to instructions before an
exception, if you never stepped through these instructions, would be
pretty much impossible to implement efficiently AFAIK.
-Jesse
--
Jesse Glick <mailto:jesse.glick@sun.com> x22801
NetBeans, Open APIs <http://www.netbeans.org/>
# 3
topic reminds me of my recent search for a "skip over" step command.
Sometimes I would
like to emulate an experiment and skip execution of some lines --
Step-to-cursor/line.
I've seen this in other debuggers and saved lots of time.
"Jesse Glick" <jesse.glick@sun.com> wrote in message
news:netbeans.nbusers/3D513E8A.6020702@sun.com...
> Gabriele Carcassi wrote:
> > is it possible in Java (and is there a feature proposal) to do step back
in
> > the debugger? That is, the ability to go to the previous line of code
when
> > doing step-by-step debugging for a limited set of instruction (say 10).
>
> Don't think so. It would be really nice though. I always get impatient
> when stepping and go past the line with the problem and have to start
over.
>
> But this could be pretty hard to implement. Consider if the Java program
> was making native calls (I/O prints, graphic repaints, ...) during this
> time period. You can't exactly undo them.
>
> Also I would bet it would be possible with some effort and caveats to
> back up a limited number of steps to a previous point where you had set
> a breakpoint or stepped to; but backing up to instructions before an
> exception, if you never stepped through these instructions, would be
> pretty much impossible to implement efficiently AFAIK.
>
> -Jesse
>
> --
> Jesse Glick <mailto:jesse.glick@sun.com> x22801
> NetBeans, Open APIs <http://www.netbeans.org/>
>
# 4
> I always get impatient
> when stepping and go past the line with the problem and have to start
over.
That's what happened yet another time before I wrote... I tend to step
through when I should step into!
I have seen debuggers that are able to do back step... I don't know how they
work though.
> possible back up a limited number of steps to a previous point
> where you had set a breakpoint [...] but backing up [...] if you never
> stepped through these instructions, [...] impossible to implement
> efficiently AFAIK.
Hhhhmmm... maybe a conditional breakpoint on the line where I expect the
exception, which is triggered by the exception itself. The debugger would
have to back up every time before the exception, even if the condition isn't
met, but it would be _much_ better than having to trace the whould
execution. Does it sound more reasonable?
I know it's a long shot...
Gabriele
# 5
Looks like something close to this is now available in the Java 2 SDK 1.4. See
[1].
Essentially, the JVMDI (Java Virtual Machine Debug Interface) now has a
PopFrame(thread) method (see [2]) which takes the top frame of the stack and
resets the thread state to the what it was in the preceding stack--essentially,
sets the thread back to just before the most recent method invocation.
So this doesn't allow you to step backwards on an arbitarry execution path (I'm
not sure I see how that could be done at all) but it does allow some form of
step-back-to-caller-and-rerun. Pretty cool.
Of course, this would need to be added to the NB debugger module.
dwh
[1] http://java.sun.com/j2se/1.4.1/docs/guide/jpda/enhancements.html#hotswap
[2] http://java.sun.com/j2se/1.4.1/docs/guide/jpda/jvmdi-spec.html#PopFrame
Jesse Glick wrote:
> Gabriele Carcassi wrote:
> > is it possible in Java (and is there a feature proposal) to do step back in
> > the debugger? That is, the ability to go to the previous line of code when
> > doing step-by-step debugging for a limited set of instruction (say 10).
>
> Don't think so. It would be really nice though. I always get impatient
> when stepping and go past the line with the problem and have to start over.
>
> But this could be pretty hard to implement. Consider if the Java program
> was making native calls (I/O prints, graphic repaints, ...) during this
> time period. You can't exactly undo them.
>
> Also I would bet it would be possible with some effort and caveats to
> back up a limited number of steps to a previous point where you had set
> a breakpoint or stepped to; but backing up to instructions before an
> exception, if you never stepped through these instructions, would be
> pretty much impossible to implement efficiently AFAIK.
>
> -Jesse
>
> --
> Jesse Glick <mailto:jesse.glick@sun.com> x22801
> NetBeans, Open APIs <http://www.netbeans.org/>
# 6
Gabriele Carcassi wrote:
<blockquote type="cite" cite="mid:aircfn$h2f$1@h74.sny.collab.net">
<pre wrap="">is it possible in Java (and is there a feature proposal) to do step back in
the debugger? That is, the ability to go to the previous line of code when
doing step-by-step debugging for a limited set of instruction (say 10).
</pre>
</blockquote>
No. This would be a nightmare to implement so don't look for it anytime
in our lifetimes. You aren't just going back a line or two (or 10). You
must restore the state that existed when first executing at that point. Imagine
the two lines:
<pre><font face="Helvetica, foo, sans-serif"> String s = "this string";</font></pre>
<pre><font face="Helvetica, foo, sans-serif"> s += " has been appended to.";</font></pre>
After the second line has been executed, the string "this string" no longer
has a reference. How would you recover it in order to go back?
This is just a simple example. Imagine if one of the lines had an explicit
method call. How do you unexecute a method?
Tomm
# 7
Gabriele Carcassi wrote:
> I have seen debuggers that are able to do back step... I don't know how they
> work though.
I assume they keep some kind of backup of the VM's (generally,
processes') heap, but I don't know for sure. If you don't save the state
of at least some memory, it seems pretty worthless to back up (you would
just see a list of instructions). Anyone have references to design
documents for such debuggers?
> Hhhhmmm... maybe a conditional breakpoint on the line where I expect the
> exception, which is triggered by the exception itself. The debugger would
> have to back up every time before the exception, even if the condition isn't
> met, but it would be _much_ better than having to trace the whould
> execution. Does it sound more reasonable?
Yes, assuming you mean "a conditional breakpoint several lines before
where I expect the exception", or something. There might be a new type
of breakpoint which just took a snapshot of state but continued, so
there would be something to back up to.
-Jesse
--
Jesse Glick <mailto:jesse.glick@sun.com> x22801
NetBeans, Open APIs <http://www.netbeans.org/>
# 8
One possibility, although maybe too confusing, is not to backstep the
current state, but to show the previous lines that were executed.
So, if you had:
1 String s = "string";
2 s = MyClass.modifyString(s);
3 System.out.println(s);
You might skip the method call (2) and end up at line 3. There you
realize that the method did something you didn't intend, and you might
want to go back "into" that method anyway.
You can't store the state information for any reasonable length of
time, but you *might* be able to store which classes/methods/lines
were called for say, 20 or 30 separate steps before a given break.
I could then review the path taken, if not the exact state, during a
debugging session. The debugger window could gray out the state
information while cycling through the history, to identify that the
current state is being shown, not the historical state.
Any thoughts?
- Phil DeJarnett
"Gabriele Carcassi" <carcassi@bnl.gov> wrote in message
news:netbeans.nbusers/aircfn$h2f$1@h74.sny.collab.net...
Hi,
is it possible in Java (and is there a feature proposal) to do step
back in
the debugger? That is, the ability to go to the previous line of code
when
doing step-by-step debugging for a limited set of instruction (say
10).
If there is, the feature that would completely change my life when
debugging
would be the: "Breakpoint 10 lines before an exception is thrown".
That is,
the program is executed until an uncatched exception is detected,
steps back
10 lines, and starts the step-by-step debugging.
Every time I have an exception, I want to see what is happening some
lines
before that. Usually I have to go through all the code, putting
breakpoint
in a good place, and sometimes it's very time consuming.
Is there something like it?
Thanks,
Gabriele
# 9
Jesse Glick wrote
> There might be a new type
> of breakpoint which just took a snapshot of state but continued, so
> there would be something to back up to.
Yes, I like it a lot! It's clean, and even more general of what I had in
mind in the first place...
Gabriele
# 10
That's true, it's not always possible to step back, but sometimes it is.
Even in the case of I/O (for example printing), sometimes it's not a
problem to execute the same operation twice. I would say that this is a
good reason to have this feature; then it's up to the developer to
decide if it's the case to go back or to restart the application.
Andrea
Jesse Glick wrote:
> Gabriele Carcassi wrote:
>
>> is it possible in Java (and is there a feature proposal) to do step
>> back in
>> the debugger? That is, the ability to go to the previous line of code
>> when
>> doing step-by-step debugging for a limited set of instruction (say 10).
>
>
> Don't think so. It would be really nice though. I always get impatient
> when stepping and go past the line with the problem and have to start over.
>
> But this could be pretty hard to implement. Consider if the Java program
> was making native calls (I/O prints, graphic repaints, ...) during this
> time period. You can't exactly undo them.
>
> Also I would bet it would be possible with some effort and caveats to
> back up a limited number of steps to a previous point where you had set
> a breakpoint or stepped to; but backing up to instructions before an
> exception, if you never stepped through these instructions, would be
> pretty much impossible to implement efficiently AFAIK.
>
> -Jesse
>
# 11
Hello all,
You can use PopFrame in NetBeans3.4 running on JDK 1.4.x (x > 0).
Lets try Debug menu / Stack / Pop Topmost Call.
So if you would like to step back, you can put breakpoint there and do
Pop TopMost + Continue.
Hanz
Denis Haskin wrote:
> Looks like something close to this is now available in the Java 2 SDK 1.4. See
> [1].
>
> Essentially, the JVMDI (Java Virtual Machine Debug Interface) now has a
> PopFrame(thread) method (see [2]) which takes the top frame of the stack and
> resets the thread state to the what it was in the preceding stack--essentially,
> sets the thread back to just before the most recent method invocation.
>
> So this doesn't allow you to step backwards on an arbitarry execution path (I'm
> not sure I see how that could be done at all) but it does allow some form of
> step-back-to-caller-and-rerun. Pretty cool.
>
> Of course, this would need to be added to the NB debugger module.
>
> dwh
>
> [1] http://java.sun.com/j2se/1.4.1/docs/guide/jpda/enhancements.html#hotswap
> [2] http://java.sun.com/j2se/1.4.1/docs/guide/jpda/jvmdi-spec.html#PopFrame
>
>
> Jesse Glick wrote:
>
>
>>Gabriele Carcassi wrote:
>>
>>>is it possible in Java (and is there a feature proposal) to do step back in
>>>the debugger? That is, the ability to go to the previous line of code when
>>>doing step-by-step debugging for a limited set of instruction (say 10).
>>>
>>Don't think so. It would be really nice though. I always get impatient
>>when stepping and go past the line with the problem and have to start over.
>>
>>But this could be pretty hard to implement. Consider if the Java program
>>was making native calls (I/O prints, graphic repaints, ...) during this
>>time period. You can't exactly undo them.
>>
>>Also I would bet it would be possible with some effort and caveats to
>>back up a limited number of steps to a previous point where you had set
>>a breakpoint or stepped to; but backing up to instructions before an
>>exception, if you never stepped through these instructions, would be
>>pretty much impossible to implement efficiently AFAIK.
>>
>>-Jesse
>>
>>--
>>Jesse Glick <mailto:jesse.glick@sun.com> x22801
>>NetBeans, Open APIs <http://www.netbeans.org/>
>>
# 12
Hi Jan,
I have tried it, and it is very useful. Although I don't understand what
would happen if I pop into a library call of which I don't have the source
code...
The only remaining question is how do I put a breakpoint on a line with a
condition on an exception thrown? I know how to put a breakpoint on an
Exception. The problem is that I want to stop only if inside a specific line
an exception is thrown, not if it is thrown by any place in the whole code!
If this is possible, we have already have something very close to what I was
hoping for!
Thanks,
Gabriele
"Jan Jancura" <jan.jancura@czech.sun.com> wrote in message
news:netbeans.nbusers/3D5231BA.9030707@czech.sun.com...
> Hello all,
> You can use PopFrame in NetBeans3.4 running on JDK 1.4.x (x > 0).
> Lets try Debug menu / Stack / Pop Topmost Call.
> So if you would like to step back, you can put breakpoint there and do
> Pop TopMost + Continue.
>
> Hanz
>
> Denis Haskin wrote:
>
> > Looks like something close to this is now available in the Java 2 SDK
1.4. See
> > [1].
> >
> > Essentially, the JVMDI (Java Virtual Machine Debug Interface) now has a
> > PopFrame(thread) method (see [2]) which takes the top frame of the stack
and
> > resets the thread state to the what it was in the preceding
stack--essentially,
> > sets the thread back to just before the most recent method invocation.
> >
> > So this doesn't allow you to step backwards on an arbitarry execution
path (I'm
> > not sure I see how that could be done at all) but it does allow some
form of
> > step-back-to-caller-and-rerun. Pretty cool.
> >
> > Of course, this would need to be added to the NB debugger module.
> >
> > dwh
> >
> > [1]
http://java.sun.com/j2se/1.4.1/docs/guide/jpda/enhancements.html#hotswap
> > [2]
http://java.sun.com/j2se/1.4.1/docs/guide/jpda/jvmdi-spec.html#PopFrame
> >
> >
> > Jesse Glick wrote:
> >
> >
> >>Gabriele Carcassi wrote:
> >>
> >>>is it possible in Java (and is there a feature proposal) to do step
back in
> >>>the debugger? That is, the ability to go to the previous line of code
when
> >>>doing step-by-step debugging for a limited set of instruction (say 10).
> >>>
> >>Don't think so. It would be really nice though. I always get impatient
> >>when stepping and go past the line with the problem and have to start
over.
> >>
> >>But this could be pretty hard to implement. Consider if the Java program
> >>was making native calls (I/O prints, graphic repaints, ...) during this
> >>time period. You can't exactly undo them.
> >>
> >>Also I would bet it would be possible with some effort and caveats to
> >>back up a limited number of steps to a previous point where you had set
> >>a breakpoint or stepped to; but backing up to instructions before an
> >>exception, if you never stepped through these instructions, would be
> >>pretty much impossible to implement efficiently AFAIK.
> >>
> >>-Jesse
> >>
> >>--
> >>Jesse Glick <mailto:jesse.glick@sun.com> x22801
> >>NetBeans, Open APIs <http://www.netbeans.org/>
> >>
>
# 13
Gabriele Carcassi wrote:
>Hi Jan,
>
>I have tried it, and it is very useful. Although I don't understand what
>would happen if I pop into a library call of which I don't have the source
>code...
>
>The only remaining question is how do I put a breakpoint on a line with a
>condition on an exception thrown? I know how to put a breakpoint on an
>Exception. The problem is that I want to stop only if inside a specific line
>an exception is thrown, not if it is thrown by any place in the whole code!
>
>If this is possible, we have already have something very close to what I was
>hoping for!
>
I have used a debugger before (I forget exactly which one -- I have used
so many) that had a Stop-At-Any-Exception mode. So you didn't have to
set any specific breakpoint. The debugger would halt execution after
the exception was thrown but before any exception handler was invoked.
Very cool.
Tomm
>
# 14
Hi,
> I have used a debugger before (I forget exactly which one -- I have
used
> so many) that had a Stop-At-Any-Exception mode. So you didn't have to
> set any specific breakpoint. The debugger would halt execution after
> the exception was thrown but before any exception handler was invoked.
> Very cool.
This is also possible in Netbeans!
Thorsten
# 15
How? Is it possible to do that with version 3.3.2? Or I need 3.4?
Andrea
Thorsten Schäfer wrote:
> Hi,
>
>>I have used a debugger before (I forget exactly which one -- I have
>
> used
>
>>so many) that had a Stop-At-Any-Exception mode. So you didn't have to
>>set any specific breakpoint. The debugger would halt execution after
>>the exception was thrown but before any exception handler was invoked.
>> Very cool.
>
>
> This is also possible in Netbeans!
>
> Thorsten
# 16
<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">Hmm, I think Borlands Turbo C had this option. They called it tracing (for obvious reasons). The output would show the file, line number and code executed. I think it even had an option to show (in a limited way) changed variables (only simply variables like int, char and such). Since the output simply appeared in a window, you could go back as much as the window could store.</FONT></P>
<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">However, execution speed was really slow, since they used an automatic breakpoint at each line of code to stop and generate the output... If I recall correctly, it was not unusual for code to execute between 100 and 1000 times slower, depending on the code.</FONT></P>
<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">-- Jan Evert</FONT>
</P>
<UL>
<P><FONT SIZE=1 FACE="Arial">--Original Message--</FONT>
<B><FONT SIZE=1 FACE="Arial">From: </FONT></B> <FONT SIZE=1 FACE="Arial">Phil DeJarnett [SMTP:phil@treeflow.com]</FONT>
<B><FONT SIZE=1 FACE="Arial">Sent: </FONT></B> <FONT SIZE=1 FACE="Arial">Wednesday, August 07, 2002 10:41 PM</FONT>
<B><FONT SIZE=1 FACE="Arial">To: </FONT></B> <FONT SIZE=1 FACE="Arial">nbusers@netbeans.org</FONT>
<B><FONT SIZE=1 FACE="Arial">Subject: </FONT> </B> <FONT SIZE=1 FACE="Arial">Re: Debugger - back step</FONT>
</P>
<P><FONT SIZE=2 FACE="Arial">One possibility, although maybe too confusing, is not to backstep the</FONT>
<FONT SIZE=2 FACE="Arial">current state, but to show the previous lines that were executed.</FONT>
</P>
<P><FONT SIZE=2 FACE="Arial">So, if you had:</FONT>
</P>
<P><FONT SIZE=2 FACE="Arial">1 String s = "string";</FONT>
<FONT SIZE=2 FACE="Arial">2 s = MyClass.modifyString(s);</FONT>
<FONT SIZE=2 FACE="Arial">3 System.out.println(s);</FONT>
</P>
<P><FONT SIZE=2 FACE="Arial">You might skip the method call (2) and end up at line 3. There you</FONT>
<FONT SIZE=2 FACE="Arial">realize that the method did something you didn't intend, and you might</FONT>
<FONT SIZE=2 FACE="Arial">want to go back "into" that method anyway.</FONT>
</P>
<P><FONT SIZE=2 FACE="Arial">You can't store the state information for any reasonable length of</FONT>
<FONT SIZE=2 FACE="Arial">time, but you *might* be able to store which classes/methods/lines</FONT>
<FONT SIZE=2 FACE="Arial">were called for say, 20 or 30 separate steps before a given break.</FONT>
</P>
<P><FONT SIZE=2 FACE="Arial">I could then review the path taken, if not the exact state, during a</FONT>
<FONT SIZE=2 FACE="Arial">debugging session. The debugger window could gray out the state</FONT>
<FONT SIZE=2 FACE="Arial">information while cycling through the history, to identify that the</FONT>
<FONT SIZE=2 FACE="Arial">current state is being shown, not the historical state.</FONT>
</P>
<P><FONT SIZE=2 FACE="Arial">Any thoughts?</FONT>
</P>
<P><FONT SIZE=2 FACE="Arial">- Phil DeJarnett</FONT>
</P>
<P><FONT SIZE=2 FACE="Arial">"Gabriele Carcassi" <carcassi@bnl.gov> wrote in message</FONT>
<FONT SIZE=2 FACE="Arial"><A HREF="news:netbeans.nbusers/aircfn$h2f$1@h74.sny.collab.net" TARGET="_blank">news:netbeans.nbusers/aircfn$h2f$1@h74.sny.collab.net</A& gt;...</FONT>
<FONT SIZE=2 FACE="Arial">Hi,</FONT>
</P>
<P><FONT SIZE=2 FACE="Arial">is it possible in Java (and is there a feature proposal) to do step</FONT>
<FONT SIZE=2 FACE="Arial">back in</FONT>
<FONT SIZE=2 FACE="Arial">the debugger? That is, the ability to go to the previous line of code</FONT>
<FONT SIZE=2 FACE="Arial">when</FONT>
<FONT SIZE=2 FACE="Arial">doing step-by-step debugging for a limited set of instruction (say</FONT>
<FONT SIZE=2 FACE="Arial">10).</FONT>
</P>
<P><FONT SIZE=2 FACE="Arial">If there is, the feature that would completely change my life when</FONT>
<FONT SIZE=2 FACE="Arial">debugging</FONT>
<FONT SIZE=2 FACE="Arial">would be the: "Breakpoint 10 lines before an exception is thrown".</FONT>
<FONT SIZE=2 FACE="Arial">That is,</FONT>
<FONT SIZE=2 FACE="Arial">the program is executed until an uncatched exception is detected,</FONT>
<FONT SIZE=2 FACE="Arial">steps back</FONT>
<FONT SIZE=2 FACE="Arial">10 lines, and starts the step-by-step debugging.</FONT>
</P>
<P><FONT SIZE=2 FACE="Arial">Every time I have an exception, I want to see what is happening some</FONT>
<FONT SIZE=2 FACE="Arial">lines</FONT>
<FONT SIZE=2 FACE="Arial">before that. Usually I have to go through all the code, putting</FONT>
<FONT SIZE=2 FACE="Arial">breakpoint</FONT>
<FONT SIZE=2 FACE="Arial">in a good place, and sometimes it's very time consuming.</FONT>
</P>
<P><FONT SIZE=2 FACE="Arial">Is there something like it?</FONT>
</P>
<P><FONT SIZE=2 FACE="Arial">Thanks,</FONT>
<FONT SIZE=2 FACE="Arial">Gabriele</FONT>
</P>
</UL>
<P><FONT SIZE=2 FACE="Arial"> &nb sp; ; & nbsp; &nb sp; ; & nbsp; &nb sp; ; & nbsp; &nb sp; ; & nbsp; </FONT></P>
<P><FONT SIZE=2 FACE="Arial"> === E U R O N E X T - D I S C L A I M E R ============================= </FONT>
</P>
<P><FONT SIZE=2 FACE="Arial"> This e-mail and its attachments are only intended for the individual(s) or entity(entities) named above to whom they are addressed and may contain personal and/or confidential information. Please notify us immediately if you are not the intended recipient. Any dissemination, duplication, publication to third parties or other use of the contents of this e-mail or its attachements is forbidden. Although this information has been compiled with great care, neither Euronext N.V. nor its subsidiaries shall accept any responsibility for any errors, omissions or other inaccuracies in this information or for the consequences thereof, nor shall it be bound in any way by the contents of this e-mail or its attachements. In the event of incomplete or incorrect transmission please return the e-mail to the sender. </FONT></P>
<P><FONT SIZE=2 FACE="Arial"> Cet e-mail et ses annexes sont uniquement destinés à la (aux) personne(s), ou à l' (aux) entité(s) à laquelle (auxquelle(s)) il est adressé, visée (s) en tête du présent message. Il peut contenir des informations personnelles ou confidentielles. Merci de nous notifier immédiatement si cet e-mail vous a été adressé par erreur. Toute diffusion, copie, publication à des tiers ou toute autre utilisation de son contenu est interdite. Bien que cette information ait été rassemblée avec une grande attention, ni Euronext N.V. ni aucune de ses filiales, ne peut être tenue responsable des erreurs, omissions ou inexactitudes contenues dans cette information, ni ne peut être liée d'aucune manière par le contenu de cet e-mail ou ses annexes. En cas de transmission incorrecte ou incomplète, nous vous prions de retourner cet e-mail à son émetteur. </FONT></P>
<P><FONT SIZE=2 FACE="Arial"> Deze e-mail en zijn bijlagen zijn uitsluitend bestemd voor de geadresseerde(n) als op dit e-mailblad vermeld. Het is mogelijk dat deze e-mail persoonlijke en/of vertrouwelijke informatie bevat. Wanneer u niet de geadresseerde bent, verzoeken wij u dringend ons daarvan te berichten. Elke verspreiding, vermenigvuldiging, gebruik of openbaarmaking aan derden van de inhoud van deze e-mail en zijn bijlagen, is verboden. Hoewel deze informatie met de meeste zorg is samengesteld is Euronext N.V., en de tot Euronext N.V. behorende werkmaatschappijen, op geen enkele wijze aansprakelijk voor eventuele fouten, omissies of andere onjuistheden in deze informatie of de gevolgen daarvan noch op enigerlei wijze gebonden aan de inhoud van de e-mail of zijn bijlagen. Gelieve, in geval van onjuiste of onvolledige ontvangst, deze e-mail terug te sturen naar de afzender. </FONT></P>
<P><FONT SIZE=2 FACE="Arial"> ================================</FONT>
</P>
# 17
Hi,
> How? Is it possible to do that with version 3.3.2? Or I need 3.4?
I'm using 3.4, so I don't know if fit works with 3.3.2. In 3.4 you go to
Debug > New Breakpoint and then you can select Exception as breakpoint
type and define the other settings.
Greetings,
Thorsten
# 18
You were right, I found the same option in 3.3.2. I'm going to try that.
And there are also some other interesting options. I have to find out
how they work.
Thanks a lot
Andrea
Thorsten Schäfer wrote:
> Hi,
>
>
>>How? Is it possible to do that with version 3.3.2? Or I need 3.4?
>
>
> I'm using 3.4, so I don't know if fit works with 3.3.2. In 3.4 you go to
> Debug > New Breakpoint and then you can select Exception as breakpoint
> type and define the other settings.
>
> Greetings,
>
> Thorsten
# 19
> This is also possible in Netbeans!
Yes, but what I am interested in is to block exceptions that come from a
specific command.
Think if you are trying to investigate on a NullPointerException... these
might be thrown by any method. I would like to trap only the ones that come
from a specific method (the one which I am investigating).
Is it possible in NetBeans to do so? Does anybody know?
Gabriele
# 20
Hi,
> Yes, but what I am interested in is to block exceptions that come from
a
> specific command.
>
> Think if you are trying to investigate on a NullPointerException...
these
> might be thrown by any method. I would like to trap only the ones that
> come
> from a specific method (the one which I am investigating).
>
> Is it possible in NetBeans to do so? Does anybody know?
I haven't done this before, but you can set a breakpoint for
NullPointerExceptions. Furthermore there's a field which allows you to
define a condition:
"A condition is a Boolean expression set on a breakpoint that triggers
the breakpoint when the expression evaluates to True."
You should read the manual to see if your problem can be solved with
that.
Greetings,
Thorsten
# 21
<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">What about a setting a breakpoint on the NullPointerException constructor?</FONT>
</P>
<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">-- Jan Evert</FONT>
</P>
<UL>
<P><FONT SIZE=1 FACE="Arial">--Original Message--</FONT>
<B><FONT SIZE=1 FACE="Arial">From: </FONT></B> <FONT SIZE=1 FACE="Arial">Gabriele Carcassi [SMTP:carcassi@bnl.gov]</FONT>
<B><FONT SIZE=1 FACE="Arial">Sent: </FONT></B> <FONT SIZE=1 FACE="Arial">Friday, August 09, 2002 2:53 PM</FONT>
<B><FONT SIZE=1 FACE="Arial">To: </FONT></B> <FONT SIZE=1 FACE="Arial">nbusers@netbeans.org</FONT>
<B><FONT SIZE=1 FACE="Arial">Subject: </FONT> </B> <FONT SIZE=1 FACE="Arial">Re: Debugger - back step</FONT>
</P>
<P><FONT SIZE=2 FACE="Arial">> This is also possible in Netbeans!</FONT>
<FONT SIZE=2 FACE="Arial">Yes, but what I am interested in is to block exceptions that come from a</FONT>
<FONT SIZE=2 FACE="Arial">specific command.</FONT>
</P>
<P><FONT SIZE=2 FACE="Arial">Think if you are trying to investigate on a NullPointerException... these</FONT>
<FONT SIZE=2 FACE="Arial">might be thrown by any method. I would like to trap only the ones that come</FONT>
<FONT SIZE=2 FACE="Arial">from a specific method (the one which I am investigating).</FONT>
</P>
<P><FONT SIZE=2 FACE="Arial">Is it possible in NetBeans to do so? Does anybody know?</FONT>
</P>
<P><FONT SIZE=2 FACE="Arial">Gabriele</FONT>
</P>
</UL>
<P><FONT SIZE=2 FACE="Arial"> &nb sp; ; & nbsp; &nb sp; ; & nbsp; &nb sp; ; & nbsp; &nb sp; ; & nbsp; </FONT></P>
<P><FONT SIZE=2 FACE="Arial"> === E U R O N E X T - D I S C L A I M E R ============================= </FONT>
</P>
<P><FONT SIZE=2 FACE="Arial"> This e-mail and its attachments are only intended for the individual(s) or entity(entities) named above to whom they are addressed and may contain personal and/or confidential information. Please notify us immediately if you are not the intended recipient. Any dissemination, duplication, publication to third parties or other use of the contents of this e-mail or its attachements is forbidden. Although this information has been compiled with great care, neither Euronext N.V. nor its subsidiaries shall accept any responsibility for any errors, omissions or other inaccuracies in this information or for the consequences thereof, nor shall it be bound in any way by the contents of this e-mail or its attachements. In the event of incomplete or incorrect transmission please return the e-mail to the sender. </FONT></P>
<P><FONT SIZE=2 FACE="Arial"> Cet e-mail et ses annexes sont uniquement destinés à la (aux) personne(s), ou à l' (aux) entité(s) à laquelle (auxquelle(s)) il est adressé, visée (s) en tête du présent message. Il peut contenir des informations personnelles ou confidentielles. Merci de nous notifier immédiatement si cet e-mail vous a été adressé par erreur. Toute diffusion, copie, publication à des tiers ou toute autre utilisation de son contenu est interdite. Bien que cette information ait été rassemblée avec une grande attention, ni Euronext N.V. ni aucune de ses filiales, ne peut être tenue responsable des erreurs, omissions ou inexactitudes contenues dans cette information, ni ne peut être liée d'aucune manière par le contenu de cet e-mail ou ses annexes. En cas de transmission incorrecte ou incomplète, nous vous prions de retourner cet e-mail à son émetteur. </FONT></P>
<P><FONT SIZE=2 FACE="Arial"> Deze e-mail en zijn bijlagen zijn uitsluitend bestemd voor de geadresseerde(n) als op dit e-mailblad vermeld. Het is mogelijk dat deze e-mail persoonlijke en/of vertrouwelijke informatie bevat. Wanneer u niet de geadresseerde bent, verzoeken wij u dringend ons daarvan te berichten. Elke verspreiding, vermenigvuldiging, gebruik of openbaarmaking aan derden van de inhoud van deze e-mail en zijn bijlagen, is verboden. Hoewel deze informatie met de meeste zorg is samengesteld is Euronext N.V., en de tot Euronext N.V. behorende werkmaatschappijen, op geen enkele wijze aansprakelijk voor eventuele fouten, omissies of andere onjuistheden in deze informatie of de gevolgen daarvan noch op enigerlei wijze gebonden aan de inhoud van de e-mail of zijn bijlagen. Gelieve, in geval van onjuiste of onvolledige ontvangst, deze e-mail terug te sturen naar de afzender. </FONT></P>
<P><FONT SIZE=2 FACE="Arial"> ================================</FONT>
</P>
# 22
> You should read the manual to see if your problem can be solved with
> that.
I did read the manual! :-)
There are two different types of breakpoints (among others): Line and
Exception. The first stops on a line if a condition is met. The second stops
on an exception if a condition is met. I want a breakpoint that stops on a
Line AND Exception. The condition is a condition on the java objects that
are in the code (like a watch expression). Or so I understood.
Is there a special object/expression that tells me on which line of which
file I am, so that I can put it as condition in an Exception breakpoint? Or
is there an object/expression that tells me if method threw an exception, so
that I can put it inside a Line breakpoint?
I haven't found that on the documentation. Maybe it's possible, maybe it's
not (and it seems to me it's the second... otherwise there would be no point
in different kinds of breakpoints: you put everything in the condition) but
I don't seem to find the answer.
The workaround I have is to create a try/catch block, and put a Line
breakpoint in the catch statement (than I can pop and re-execute the
method).
Just wanted to check if I understand things correctly...
Gabriele
# 23
Hi,
> There are two different types of breakpoints (among others): Line and
> Exception. The first stops on a line if a condition is met. The second
> stops
> on an exception if a condition is met. I want a breakpoint that stops
on a
> Line AND Exception. The condition is a condition on the java objects
that
> are in the code (like a watch expression). Or so I understood.
>
> Is there a special object/expression that tells me on which line of
which
> file I am, so that I can put it as condition in an Exception
breakpoint?
> Or
> is there an object/expression that tells me if method threw an
exception,
> so
> that I can put it inside a Line breakpoint?
>
> I haven't found that on the documentation. Maybe it's possible, maybe
it's
> not (and it seems to me it's the second... otherwise there would be no
> point
> in different kinds of breakpoints: you put everything in the
condition)
> but
> I don't seem to find the answer.
>
> The workaround I have is to create a try/catch block, and put a Line
> breakpoint in the catch statement (than I can pop and re-execute the
> method).
Hmmm, I haven't tried this ever before. But I would search in the
java-API for possibilities of accessing the stacktrace and then define a
condition. Don't know if it works...
Bye,
Thorsten
# 24
Gabriele,
VisualAge for Java was the only IDE I know of that did this. You could
be stepping through the method, change the source code, save it and
the IDE would do an incremental compile and move the debugger back to
the start of the method to pick up your changes.
The only way that this was possible was by using a custom JVM which
meant that VA Java was always 12-18 months behind the latest JVM
release which eventually led to its downfall.
Thursday, August 8, 2002, 12:56:31 AM, Gabriele Carcassi wrote:
GC> Hi,
GC> is it possible in Java (and is there a feature proposal) to do step back in
GC> the debugger? That is, the ability to go to the previous line of code when
GC> doing step-by-step debugging for a limited set of instruction (say 10).
GC> If there is, the feature that would completely change my life when debugging
GC> would be the: "Breakpoint 10 lines before an exception is thrown". That is,
GC> the program is executed until an uncatched exception is detected, steps back
GC> 10 lines, and starts the step-by-step debugging.
GC> Every time I have an exception, I want to see what is happening some lines
GC> before that. Usually I have to go through all the code, putting breakpoint
GC> in a good place, and sometimes it's very time consuming.
GC> Is there something like it?
GC> Thanks,
GC> Gabriele
--
regards,
Peter Kelley
MoveIt Pty Ltd
It isn't that they can't see the solution. It is that they can't see
the problem. - G. K. Chesterton
# 25
I think I read somewhere that NB can do this using the debugger in JDK
1.4. Although it won't backstep, you can change (fix) code while
debugging and continu debugging without the need to restart. The
debugger will pickup the new code next time it enters the method. At
least that's what I remember from what I read, I might be wrong, then
again I might be right.
Iwan
--Original Message--
From: Peter Kelley [mailto:peterk@moveit.com.au]
Sent: Tuesday, August 13, 2002 04:01
To: Gabriele Carcassi
Subject: Re: Debugger - back step
Gabriele,
VisualAge for Java was the only IDE I know of that did this. You could
be stepping through the method, change the source code, save it and the
IDE would do an incremental compile and move the debugger back to the
start of the method to pick up your changes.
The only way that this was possible was by using a custom JVM which
meant that VA Java was always 12-18 months behind the latest JVM release
which eventually led to its downfall.
Thursday, August 8, 2002, 12:56:31 AM, Gabriele Carcassi wrote:
GC> Hi,
GC> is it possible in Java (and is there a feature proposal) to do step
GC> back in the debugger? That is, the ability to go to the previous
GC> line of code when doing step-by-step debugging for a limited set of
GC> instruction (say 10).
GC> If there is, the feature that would completely change my life when
GC> debugging would be the: "Breakpoint 10 lines before an exception is
GC> thrown". That is, the program is executed until an uncatched
GC> exception is detected, steps back 10 lines, and starts the
GC> step-by-step debugging.
GC> Every time I have an exception, I want to see what is happening some
GC> lines before that. Usually I have to go through all the code,
GC> putting breakpoint in a good place, and sometimes it's very time
GC> consuming.
GC> Is there something like it?
GC> Thanks,
GC> Gabriele
--
regards,
Peter Kelley
MoveIt Pty Ltd
It isn't that they can't see the solution. It is that they can't see the
problem. - G. K. Chesterton
# 26
First, great product. (Using NB3.3 cause we're deploying with
tomcat 3.2, Can I use 3.4 with the older tomcat?).
Next, a question...
I want an applet to talk to a servlet. I create
a web application, and put the servlet under classes/(packagename)/whatever.
I put the applet at the top level. Everything works, I can
execute the html that starts the applet, and it talks to
the servlet. Fantastic.
Now I want to pass serialized objects between the applet
and the servlet, specifically a class with no methods, like
a C structure.
I create the class under classes/packagename/whatever, and
everything compiles fine.
BUT! when I run the applet it can't find the class file.
So where do I put the class files for the structure that
I want to pass back and forth. Surely I shouldn't have
two copies of the file! I've tried links but I couldn't
get it to work.
The best I've come up with is to have the shared classes
in a subdirectory with the package name under the
Document Base. (Why is my filesystem view different
from my project view?). But this is ugly from a code
reuse point of view -- the package under Classes should
be self-contained. I.E. if I jar it up it should be
complete.
Any ideas?
I guess my real problem is that I dont' understand
what the effective CLASSPATH is at compile time and
at run-inside-tomcat time.
-- cary
# 27
Hi Cary,
# First, great product.
Thank you!
# Can I use 3.4 with [tomcat 3.2] ?
Netbeans 3.4 has support for executing on separately installed
instances of Tomcat 4.0.X (modulo some bugs in Tomcat, in practice
Tomcat 4.0.1 and 4.0.4 are OK), so unfortunately it is not possible to
configure it to use Tomcat 3.X as its execution environment.
For most of the JSP and Servlet specifications there were no major
changes between the versions supported by Netbeans 3.3 and Netbeans
3.4. The one major exception is tag libraries. Netbeans 3.4 includes a
tag library editor (as an auto-update module); this module created tag
libraries that will not run on Tomcat 3.2. Netbeans 3.4 also supports
some other parts of the Servlet spec that were not part of Servlet
2.2, e.g. Filters.
As long as you are careful to avoid using features from the JSP and
Servlet specs that were not present in the versions that Tomcat 3.2
supports, you should be able to use Netbeans 3.4 to develop web
modules. This will also allow you to use some features that were
previously only present in Forte for Java, such as the HTTP
Monitor. This tool lets you track data flow in and out of the
different web components, and to replay HTTP requests for debugging
purposes (start from the Toobar: Debug -> HTTP Monitor).
# Next, a question...
#
# I want an applet to talk to a servlet. I create a web application,
# and put the servlet under classes/(packagename)/whatever. I put the
# applet at the top level. Everything works, I can execute the html
# that starts the applet, and it talks to the servlet. Fantastic.
#
# Now I want to pass serialized objects between the applet
# and the servlet, specifically a class with no methods, like
# a C structure.
#
# I create the class under classes/packagename/whatever, and
# everything compiles fine.
#
# BUT! when I run the applet it can't find the class file.
This is a limitation imposed by the Servlet specification. The
resources under WEB-INF cannot be requested directly by an external
client. Only the servlet engine can access these directly. So if you
put a JSP under WEB-INF docs for example, it cannot be requested
directly by entering http://host.domain/WEB-INF/docs/my.jsp, though it
could be accessed indirectly if the browser points to
http://host.domain/some.jsp and either this JSP or a servlet which
intercepts the request and forwards to or includes
WEB-INF/docs/my.jsp.
When you deploy an applet, what happens is that the HTML file that
declares the applet specifies how to download the applet's
class(es). When the browser parses the file, it issues a HTTP request
for those classes, or for a jar file that contains them. This HTTP
request must point to a resource that is not under WEB-INF, just as in
the case of my.jsp above. Hence the classes in WEB-INF/classes are
available to the servlet but not to the applet, and you do in fact
have to make the same class available twice in the same web module.
# So where do I put the class files for the structure that
# I want to pass back and forth. Surely I shouldn't have
# two copies of the file! I've tried links but I couldn't
# get it to work.
You should be able to use links in principle. I know there are some
problems with links in web modules; perhaps this is an issue here.
In practice though, if you're applet needs more than one class to
work, it's better to package it as a jar file than to make the classes
available individually. In the latter case, the applet will make one
HTTP request for the class that's listed in the applet declaration,
and then additional HTTP requests for each other class that's needed
which increases network traffic. If you package all the classes that
are needed into a single jar, then there will only be one HTTP
request.
So I suggest that you create a jar file which contains all the classes
needed for the applet and place that in some suitable place under the
web module root. This does amount to including the same class file
more than once in a single web module (as you correctly observe),
though that's likely to be the cleanest and best performing solution
in this case. (By the way, unless the data you need to send is very
complex, it is likely that the app will perform even better if you
avoid using serialization altogether and send the data as raw text).
Ana
# 28
Symatic visual cafe had this feature in jdk 1.1.
I used to use it heavily
Mike
> --Original Message--
> From: Iwan [mailto:java@i-ware.net]
> Sent: Tuesday 13 August 2002 17:08
> To: nbusers@netbeans.org
> Subject: RE: Debugger - back step
>
>
> I think I read somewhere that NB can do this using the
> debugger in JDK 1.4. Although it won't backstep, you can
> change (fix) code while debugging and continu debugging
> without the need to restart. The debugger will pickup the new
> code next time it enters the method. At least that's what I
> remember from what I read, I might be wrong, then again I
> might be right.
>
> Iwan
>
> --Original Message--
> From: Peter Kelley [mailto:peterk@moveit.com.au]
> Sent: Tuesday, August 13, 2002 04:01
> To: Gabriele Carcassi
> Subject: Re: [nbusers] Debugger - back step
>
>
> Gabriele,
>
> VisualAge for Java was the only IDE I know of that did this.
> You could be stepping through the method, change the source
> code, save it and the IDE would do an incremental compile and
> move the debugger back to the start of the method to pick up
> your changes.
>
> The only way that this was possible was by using a custom JVM
> which meant that VA Java was always 12-18 months behind the
> latest JVM release which eventually led to its downfall.
>
> Thursday, August 8, 2002, 12:56:31 AM, Gabriele Carcassi wrote:
>
> GC> Hi,
>
> GC> is it possible in Java (and is there a feature proposal)
> to do step
> GC> back in the debugger? That is, the ability to go to the previous
> GC> line of code when doing step-by-step debugging for a
> limited set of
> GC> instruction (say 10).
>
> GC> If there is, the feature that would completely change my life when
> GC> debugging would be the: "Breakpoint 10 lines before an
> exception is
> GC> thrown". That is, the program is executed until an uncatched
> GC> exception is detected, steps back 10 lines, and starts the
> GC> step-by-step debugging.
>
> GC> Every time I have an exception, I want to see what is
> happening some
>
> GC> lines before that. Usually I have to go through all the code,
> GC> putting breakpoint in a good place, and sometimes it's very time
> GC> consuming.
>
> GC> Is there something like it?
>
> GC> Thanks,
> GC> Gabriele
>
>
>
>
> --
>
> regards,
> Peter Kelley
>
> MoveIt Pty Ltd
>
> It isn't that they can't see the solution. It is that they
> can't see the problem. - G. K. Chesterton
>
# 29
Hello Gabriele,
I understand your requirement, but this feature is not implemented in
current NetBeans debugger. Can you create some RFE in issuezilla, please?
Thanks,
Jan
Gabriele Carcassi wrote:
>>You should read the manual to see if your problem can be solved with
>>that.
>>
> I did read the manual! :-)
>
> There are two different types of breakpoints (among others): Line and
> Exception. The first stops on a line if a condition is met. The second stops
> on an exception if a condition is met. I want a breakpoint that stops on a
> Line AND Exception. The condition is a condition on the java objects that
> are in the code (like a watch expression). Or so I understood.
>
> Is there a special object/expression that tells me on which line of which
> file I am, so that I can put it as condition in an Exception breakpoint? Or
> is there an object/expression that tells me if method threw an exception, so
> that I can put it inside a Line breakpoint?
>
> I haven't found that on the documentation. Maybe it's possible, maybe it's
> not (and it seems to me it's the second... otherwise there would be no point
> in different kinds of breakpoints: you put everything in the condition) but
> I don't seem to find the answer.
>
> The workaround I have is to create a try/catch block, and put a Line
> breakpoint in the catch statement (than I can pop and re-execute the
> method).
>
> Just wanted to check if I understand things correctly...
>
> Gabriele
>
>
# 30
Hi Jan,
Thanks for the anwser. I filed a RFE in issuzilla.
http://www.netbeans.org/issues/show_bug.cgi?id=26505
Gabriele
"Jan Jancura" <jan.jancura@czech.sun.com> wrote in message
news:netbeans.nbusers/3D5A4A5F.9090206@czech.sun.com...
> Hello Gabriele,
>
> I understand your requirement, but this feature is not implemented in
> current NetBeans debugger. Can you create some RFE in issuezilla, please?
>
> Thanks,
> Jan
>
>
> Gabriele Carcassi wrote:
>
> >>You should read the manual to see if your problem can be solved with
> >>that.
> >>
> > I did read the manual! :-)
> >
> > There are two different types of breakpoints (among others): Line and
> > Exception. The first stops on a line if a condition is met. The second
stops
> > on an exception if a condition is met. I want a breakpoint that stops on
a
> > Line AND Exception. The condition is a condition on the java objects
that
> > are in the code (like a watch expression). Or so I understood.
> >
> > Is there a special object/expression that tells me on which line of
which
> > file I am, so that I can put it as condition in an Exception breakpoint?
Or
> > is there an object/expression that tells me if method threw an
exception, so
> > that I can put it inside a Line breakpoint?
> >
> > I haven't found that on the documentation. Maybe it's possible, maybe
it's
> > not (and it seems to me it's the second... otherwise there would be no
point
> > in different kinds of breakpoints: you put everything in the condition)
but
> > I don't seem to find the answer.
> >
> > The workaround I have is to create a try/catch block, and put a Line
> > breakpoint in the catch statement (than I can pop and re-execute the
> > method).
> >
> > Just wanted to check if I understand things correctly...
> >
> > Gabriele
> >
> >
>
# 31
<P><FONT SIZE=2>Following on from recent discussions about stepping back in a debugger, it seems someone has written a debugger which can do this:</FONT></P>
<P><FONT SIZE=2><A HREF="http://java.sun.com/features/2002/08/omnidebug.html" TARGET="_blank">http://java.sun.com/features/2002/08/omnidebug.html</A> ;</FONT>
</P>
<P><FONT SIZE=2>--Original Message--</FONT>
<FONT SIZE=2>From: Gabriele Carcassi [<A HREF="mailto:carcassi@bnl.gov">mailto:carcassi@bnl.gov</A>]</FONT&g t;
<FONT SIZE=2>Sent: 07 August 2002 15:57</FONT>
<FONT SIZE=2>To: nbusers@netbeans.org</FONT>
<FONT SIZE=2>Subject: Debugger - back step</FONT>
</P>
<P><FONT SIZE=2>Hi,</FONT>
</P>
<P><FONT SIZE=2>is it possible in Java (and is there a feature proposal) to do step back in</FONT>
<FONT SIZE=2>the debugger? That is, the ability to go to the previous line of code when</FONT>
<FONT SIZE=2>doing step-by-step debugging for a limited set of instruction (say 10).</FONT>
</P>
<P><FONT SIZE=2>If there is, the feature that would completely change my life when debugging</FONT>
<FONT SIZE=2>would be the: "Breakpoint 10 lines before an exception is thrown". That is,</FONT>
<FONT SIZE=2>the program is executed until an uncatched exception is detected, steps back</FONT>
<FONT SIZE=2>10 lines, and starts the step-by-step debugging.</FONT>
</P>
<P><FONT SIZE=2>Every time I have an exception, I want to see what is happening some lines</FONT>
<FONT SIZE=2>before that. Usually I have to go through all the code, putting breakpoint</FONT>
<FONT SIZE=2>in a good place, and sometimes it's very time consuming.</FONT>
</P>
<P><FONT SIZE=2>Is there something like it?</FONT>
</P>
<P><FONT SIZE=2>Thanks,</FONT>
<FONT SIZE=2>Gabriele</FONT>
</P>
<P><FONT SIZE=2>__ </FONT>
<FONT SIZE=2>This electronic message contains information which may be privileged and confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone on 0131 476 6000 and delete the material from your computer.</FONT></P>
# 32
Yes, I know. But they use different technology than JPDA. Have you
tested it? I have heard that its very slow.
Jan
Robbie Baldock wrote:
> Following on from recent discussions about stepping back in a debugger,
> it seems someone has written a debugger which can do this:
>
> http://java.sun.com/features/2002/08/omnidebug.html
>
> --Original Message--
> From: Gabriele Carcassi [mailto:carcassi@bnl.gov]
> Sent: 07 August 2002 15:57
> To: nbusers@netbeans.org
> Subject: Debugger - back step
>
>
> Hi,
>
> is it possible in Java (and is there a feature proposal) to do step back in
> the debugger? That is, the ability to go to the previous line of code when
> doing step-by-step debugging for a limited set of instruction (say 10).
>
> If there is, the feature that would completely change my life when
> debugging
> would be the: "Breakpoint 10 lines before an exception is thrown". That is,
> the program is executed until an uncatched exception is detected, steps
> back
> 10 lines, and starts the step-by-step debugging.
>
> Every time I have an exception, I want to see what is happening some lines
> before that. Usually I have to go through all the code, putting breakpoint
> in a good place, and sometimes it's very time consuming.
>
> Is there something like it?
>
> Thanks,
> Gabriele
>
>
>
> __
> This electronic message contains information which may be privileged and
> confidential. The information is intended to be for the use of the
> individual(s) or entity named above. If you are not the intended
> recipient, be aware that any disclosure, copying, distribution or use of
> the contents of this information is prohibited. If you have received
> this electronic message in error, please notify us by telephone on 0131
> 476 6000 and delete the material from your computer.
>
