Disabling "Break on Exception" in compiler directives ??
Bjørge Sæther
>On Sun, 17 Oct 1999 22:40:51 +0200, "Bjørge Sæther"
><REMOVE_...@online.no> wrote:
>
>>Hi !
>>
>>Is it possible to switch on/off "Break on exception" in *Code*
>>(compiler directives) like one may do with warnigs (D3..D4) ? Maybe
in
>>D5 ??
>
>What do you want to happen? You can install a new default exception
>handler in Application.OnException; you can't tell Delphi to ignore
>errors and proceed (because it doesn't always make sense to do so).
>For example, if you ask for the 10th element of a 9 element
>collection, what do you want to get?
When working with databases, there is occasionally exceptions that is
likely to occur (like various metadata manipulation) and that is
properly handled by code. I would like to be able to debug these kinds
of applications without necessarily sitting in front of the app
pushing "OK" to error messages that pop up. All other places in my
code, I'd like exceptions to pause execution.
This should be easy, as you AMOF may toggle "Break on Exception"
onn/off while execution.
But - is it possible ?
--
Bjoerge
Robert Rossmair
Duncan Murdoch wrote:
> What do you want to happen? You can install a new default exception
> handler in Application.OnException; you can't tell Delphi to ignore
> errors and proceed (because it doesn't always make sense to do so).
"Break on exception" is a debugger option in Delphi, which causes the
debugger to pause program execution and jump to the corresponding line
of code whenever an exception occurs. It has nothing to do with
exception handling.
Greetings, Robert
th...@my-deja.com
No, but the exception handling will be the next thing it will do.
>
> Greetings, Robert
>
>
What the original poster, and me too!, would like to know is can you
alter this setting in your code with a directive. If you create an
exception in your code during execution, the debugger will display a
dialog box telling you that an exception has occured. You can click the
OK button and step to the next line which will be in your exception
handler code and continue to debug. HOWEVER, if you know the exception
IS going to occur as a normal part of execution it would be nice to be
able to NOT break on this exception and just go immediately to the next
line in your code which would of course be in the exception handler. It
is just a pain to have to keep pressing the stupid OK button, it breaks
the flow of thought :-)
Trevor
Sent via Deja.com http://www.deja.com/
Before you buy.
Duncan Murdoch
Robert Lee suggested an exception-specific way to do what you want.
If you want total programmatic control, what you could do is set
"Break on Exception" off in the debugger, and then manually trigger a
break whenever you want one, e.g. in the application.OnException
handler.
To trigger a break, just execute an INT 3 instruction. This is the
"trap to debugger" interrupt.
procedure BreakNow; assembler;
asm
int 3
end;
I just tried this, and it works in D3 under Win95; I don't guarantee
it works anywhere else.
Duncan Murdoch
Ray Lischner
<REMOVE_...@online.no> wrote:
>Is it possible to switch on/off "Break on exception" in *Code*
>(compiler directives) like one may do with warnigs (D3..D4) ? Maybe in
>D5 ??
Not with a compiler directive, but by assigning to the ExceptionClass
variable. Delphi's IDE breaks only for classes that inherit from
ExceptionClass (or all exceptions if ExceptionClass is nil). Thus, if
you want to raise an exception and NOT have the IDE stop, you can raise
an exception that does not inherit from Exception (which is the value of
ExceptionClass if you use the SysUtils unit), or you can temporarily set
ExceptionClass to something different.
--
Ray Lischner, http://www.tempest-sw.com/
author of Delphi in a Nutshell
Alex McMorris
the real issue... how do you find a REAL exception without having to sift
through possibly hundreds of acceptable (handled) exceptions?
Duncan Murdoch <dmur...@pair.com> wrote in message
news:380e1000...@newshost.uwo.ca...
Alex McMorris
by StrToInt or BDE stuff or other such things that we have already handed
the failure case on.
My suggestion is in the next build of Delphi include a sub checkbox to the
break on exception checkbox that says: Ignore exceptions in try blocks. If
you really want to see one, keep this unchecked or put a breakpoint in...
Ray Lischner <lisch.at.te...@nojunkmail.com> wrote in message
news:RZALOCkgJee9+r...@4ax.com...
Ray Lischner
<al...@simply-smarter.com> wrote:
>But the exceptions we want to avoid breaking on are automatically generated
>by StrToInt or BDE stuff or other such things that we have already handed
>the failure case on.
Then set ExceptionClass before calling StrToInt or whatever. Then change
it back after the function returns.
Or let the user decide what should or should not stop the IDE, which is
who should be making the decision, anyway.
Bjørge Sæther
Thanks for the tip ! I will try that one...
--
Bjoerge
Alex McMorris
tells it) which exceptions--and possibly on which lines--to ignore... having
to change the ExceptionClass before and after ANY potential exception just
for debugging is added overhead... I guess if you compare to a const value
(const DBUG = False;) wouldn't compile into the exe... I still think it
should be an IDE implementation and not a source impementation--it reaks of
hack.
Ray Lischner <lisch.at.te...@nojunkmail.com> wrote in message
news:S6QLOLKc2Mu0OH...@4ax.com...
Bjørge Sæther
--
Bjoerge
Ray Lischner skrev i meldingen ...
>On Sun, 17 Oct 1999 22:40:51 +0200, "Bjørge Sæther"
><REMOVE_...@online.no> wrote:
>
>>Is it possible to switch on/off "Break on exception" in *Code*
>>(compiler directives) like one may do with warnigs (D3..D4) ? Maybe
in
>>D5 ??
>
>Not with a compiler directive, but by assigning to the ExceptionClass
>variable. Delphi's IDE breaks only for classes that inherit from
>ExceptionClass (or all exceptions if ExceptionClass is nil). Thus, if
>you want to raise an exception and NOT have the IDE stop, you can
raise
>an exception that does not inherit from Exception (which is the value
of
>ExceptionClass if you use the SysUtils unit), or you can temporarily
set
>ExceptionClass to something different.
Duncan Murdoch
<al...@simply-smarter.com> wrote:
>What about getting back to the line that caused the exception... which is
>the real issue... how do you find a REAL exception without having to sift
>through possibly hundreds of acceptable (handled) exceptions?
If you call Breaknow (from my earlier message), then just look at the
stack dump (View|Stack) to see where it was called from.
Duncan Murdoch
Alex McMorris
breakpoint and the BreakNow procedure call and in either case the call stack
is useless. In the case of the BreakNow procedure the call stack just has a
unit name (not the one that had the exception either)... and in the case of
the breakpoint there is just...er... this:
TSBase.ApplicationException(Ptr($7747,$C),Ptr($772f,$4C))
How is this useful?
Maybe this is a tougher exception because it is a GPF... So if that's the
case never mind my ranting :)
Thanks,
Alex
Duncan Murdoch <dmur...@pair.com> wrote in message
news:380ccb5...@newshost.uwo.ca...
Duncan Murdoch
<al...@simply-smarter.com> wrote:
>How does that help? I have Application.OnException set and I have a
>breakpoint and the BreakNow procedure call and in either case the call stack
>is useless. In the case of the BreakNow procedure the call stack just has a
>unit name (not the one that had the exception either)... and in the case of
>the breakpoint there is just...er... this:
Yes, you're right. By the time the Breaknow procedure is called, the
call stack will be messed up.
>
>TSBase.ApplicationException(Ptr($7747,$C),Ptr($772f,$4C))
>
>How is this useful?
See the online help for the TExceptionEvent call. The first pointer
is to the object that raised the exception, the second is to the
exception object. You can look at those for clues about what went
wrong; you can also examine the global ExceptAddr variable to find the
location where the exception occurred.
I don't know a simple way to trick the debugger into jumping to
ExceptAddr, but you can raise another exception at the same address
(which is descended from a type that does cause the debugger to stop)
using syntax like
target := ExceptAddress;
if assigned(target) then
raise MyException.Create('Requested exception at
'+IntToHex(integer(target),8)) at target;
Duncan Murdoch
Alex McMorris
Alex
Duncan Murdoch <dmur...@pair.com> wrote in message
news:380ca60d...@newshost.uwo.ca...
VBDis
<al...@simply-smarter.com> schreibt:
>I still think it
>should be an IDE implementation and not a source impementation--it reaks of
>hack.
Just a question: does anybody know, where the debugger information is stored,
telling on which exceptions to break? I couldn't locate that information in the
DOF and other files.
DoDi
Alex McMorris
added, it doesn't exist.
VBDis <vb...@aol.com> wrote in message
news:19991020080239...@ngol03.aol.com...
Duncan Murdoch
<al...@simply-smarter.com> wrote:
>Telling on which exceptions to break? That is what I (for one) want to see
>added, it doesn't exist.
No, that was already pointed out by someone else: the ExceptionClass
global (in the System unit) is the base class for exceptions that
should cause a break in the debugger. Set it to some special class,
and only descendants of that kind of exception will cause breaks.
For example,
procedure TForm1.Button1Click(Sender: TObject);
begin
exceptionclass := EMatherror;
raise exception.create('raised');
end;
procedure TForm1.Button2Click(Sender: TObject);
begin
exceptionclass := EMatherror;
raise Ematherror.create('matherror');
end;
Only the second of these causes a break to the debugger.
Duncan Murdoch