Yes:

{$IFOPT C}
   Uses UDebug;
{$endif}

But this won't work if in general assertionas are off and you do somewhere in your code:

{$ASSERTIONS ON}
  some code
{$ASSERTIONS OFF}

Assertions is a local switch, So better to include the unit always.

Michael.

The exception will not be fired if you override the asserterrorproc;
sysutils sets its value to an internal procedure.

If you set its value, your procedure will be called, and no exception is raised.

Michael.

No, just create your own assert handler.

Procedure AssertErrorHandler (Const Msg,FN : String;LineNo,TheAddr :Longint);
Var
  S : String;
begin
  If Msg='' then
    S:=SAssertionFailed
  else
    S:=Msg;
  WriteLn(StdErr,Format(SAssertError,[S,Fn,LineNo]));
end;

And init it with

;

Peter

This is the default behaviour; if you set the procedural variable 'asserterrorproc' then you can customize the behaviour; the application just continues after the assertion handler.

careful; the systutils unit sets the handler, and turns it into an exception. you must be sure that sysutils doesn't override your handler. (normally, it should not)

Michael.

OK guys it seems to be 6 of one, half a dozen of another. Which way do we go at this? The Assertion method does seem to be fairly clean. It is there an only compiled it when the $ASSERTION switch is turned on.

Now my question is can we monitor this switch in the code? If so then we can make sure that the udebug unit is also not included in the code.

Hello,

May I remind you that the compiler supports the ASSERT() construct of Delphi; that you can specify a
AssertErrorProc
which takes care of the asserts ?

This means that you can have the whole debug class stuff without the juggling with macros.

Just do a

 Assert(False,'Some debug message');

The assertErrorProc will then give you the line number, source file and this message.

Assert code is compiled in or not depending on the LOCAL switch:
{$ASSERTIONS ON}

So they can be switched on or off at will, if they are off, no code is even generated.

better yet; you can implement debug levels thus:

 Assert(Debug.Debuglevel>2,'Some serious error');
 Assert(Debug.DebugLevel=3,'Some esoteric error');

Just an idea; why use ugly constructs with macros if you can have more (i.e. source and line number) with this compiler construct ?

Michael.

Correction: The default behaviour is to print the error on StdErr, and then to continue the program.

The sysutils unit does make it an exception.

Michael.

So now are you saying that it will always abort the program? Does modifing 'asserterrorproc' just change how or what is output and the exception is fired regardless or can we circumvent the exception being fired as well?

The debugging stuff should really be in the gtkint unit if you ask me we can treat it just as we do any other component code. This would allow other tool kits to implement how and where that type of thing is displayed.

Cliff

For the macro way seems the better because the code will run the same with or without the debug code. With $Assertion we may have wifferences in the way of handling exceptions.

JDB

les opinions et recommandations exprim�es dans ce courrier sont ceux de l'auteur, ils ne sont pas n�cessairement endoss�s par Agritulture et AgroAlimentaire Canada
-------------------------------------------------------------- Philippe JEAN DIT BAILLEUL
Agriculture & AgroAlimentaire Canada - Agriculture & AgriFood Canada Email :
Web : Http://res.agr.ca/swinenet/porcexpert/jeanditbailleulp Tel : +1 (819) 565 9174 poste 251
Fax : +1 (819) 564 5507

But doesn't the Assert abort the application after it is called? We want to use the debug as a tracing feature to give us processing out of the code as it runs. This would print the Assert line and stop. Or am I misunderstanding how Assert is used in FPC?

Even in gtk and all other big libraries asserts are used. See all the error messages from gtk you'll get, they are all assert() calls.

Peter

You only need a debug unit which sets the assertproc. And it only needs to be included once instead of every unit.

Peter

Peter Vreman wrote

You only need a debug unit which sets the assertproc. And it only needs to be included once instead of every unit.

Unless you want to display by debugLevels then the unit would need to include the debug unit.

yep add it to the cvs when ready...

Cliff

OK cool! I think we should opt for this method then. Hey Cliff since this is really changing how TDebug is currently designed how about if I make all the modifications to the udebug unit so that it will work with Assertions. When that is done I'll commit it to CVS and then we can start adding it to the code.

I'll recode this tonight and add it.