BorlandTalk.com

Lauchlan M · Guest

It's simple enough to do anyway, but out of interest:

What logging components are there out there?

Do people use them?

What advantages do they offer?

Which ones do you use?

Basically I mean something that would take a handled exception and log
whatever details you give it to file. Normally I'd just log to a text file,
but if I used a logging component I guess it would be better if it gave me
options, eg to text file, XML, binary, database, etc.

It should do all the obvious and normal things, eg record the error
name/category and details I pass to it, attach a timestamp, attach a userID
if appropriate, etc.

If it were reasonably clever, it would have logic to allow you to configure
whether to record every error, or just the first instance of each (perhaps
with a running total of how many times and how frequently it has been
occuring).

Or maybe everyone's logging requirements are individual/specific anyway, so
everyone just rolls their own.

By logging components, I specifically DON'T MEAN components for catching
UNHANDLED exceptions like MadExcept, EurekaLog, etc. I'm interested in what
you do (or don't) use to log HANDLED exceptions and errors.

Thanks

Lauchlan M

Danijel Tkalcec · Guest

I think Logging is pretty much individual, so that usualy everyone has their
own version.
I've used different versions of log units over the past years, most of them
simply for writing into a textfile.
For logging database actions, it depends on the database structure and
things you want to log (also, where you want to log them).

I think its best to log everything you think is worth logging,
then have a separate program to summarize this information on stuff you feel
like summarizing.

Here is the log-writing unit I use for most apps today.
It is simple to use, thread-safe and there are no special preparations
needed
(call "StartLog" to enable, "StopLog" to disable logging and "Log"/"XLog" to
add to the log).
You could create a class from this, but it's easier to use as set of
procedures.
----------------------------------------
{
@html()
Log File Creation
@html()
- Copyright (c) Danijel Tkalcec
@html(

)

This unit gives you thread-safe Log writing support.
}
unit rtcLog;

interface

uses
SysUtils, SyncObjs, Windows;

var
{ Write Logged exception into the Log file?
Dafault=True. By changing this to False will remove any
Connection component exceptions from the Log file. }
LOG_EXCEPTIONS:boolean=True;

{ Write exception with a short string description into the Global App Log
file.
This procedure will have no effect if Log writer not started
(by calling StartLog) or LOG_EXCEPTIONS is @false }
procedure Log(s:string; E:Exception; const name:string=''); overload;

{ Write message into the Global App Log file.
This procedure will have no effect if Log writer not started. }
procedure Log(s:string; const name:string=''); overload;

{ Write message into the Log file for the current date.
This procedure will have no effect if Log writer not started. }
procedure XLog(s:string; const name:string=''); overload;

{ Before Log() procedures will have any effect,
you have to call this procedure to start the Log writer.
Without it, no Log file. }
procedure StartLog;

{ To stop Log file creation, simply call this procedure.
To continue log writing, call StartLog. }
procedure StopLog;

implementation

var
ThrCS:TCriticalSection;
doLog:boolean=False;

procedure StartLog;
begin
ThrCS.Enter;
try
doLog:=True;
finally
ThrCS.Leave;
end;
end;

procedure StopLog;
begin
ThrCS.Enter;
try
doLog:=False;
finally
ThrCS.Leave;
end;
end;

procedure XLog(s:string; const name:string='');
var
f:TextFile;
d:TDateTime;
fname,
s2:string;
begin
ThrCS.Enter;
try
if not doLog then Exit; // Exit here !!!!

try
d:=Now;
s2:=FormatDateTime('[yyyy-mm-dd hh:nn:ss] ',d);

if name<>'' then
fname:=ParamStr(0)+'.'+FormatDateTime('yyyy_mm_dd',d)+'.'+name+'.log'
else
fname:=ParamStr(0)+'.'+FormatDateTime('yyyy_mm_dd',d)+'.log';

Assign(f,fname);
{$I-}
Append(f);
{$I+}
if IOREsult<>0 then
Rewrite(f);
try
Writeln(f,s2+s);
finally
CloseFile(f);
end;
except
end;

finally
ThrCS.Leave;
end;
end;

procedure Log(s:string; const name:string='');
var
f:TextFile;
d:TDateTime;
fname,
s2:string;
begin
ThrCS.Enter;
try
if not doLog then Exit; // Exit here !!!!

try
d:=Now;
s2:=FormatDateTime('[yyyy-mm-dd hh:nn:ss] ',d);
if name<>'' then
fname:=ParamStr(0)+'.'+name+'.log'
else
fname:=ParamStr(0)+'.log';

Assign(f,fname);
{$I-}
Append(f);
{$I+}
if IOREsult<>0 then
Rewrite(f);
try
Writeln(f,s2+s);
finally
CloseFile(f);
end;
except
end;

finally
ThrCS.Leave;
end;
end;

procedure Log(s:string; E:Exception; const name:string='');
begin
if LOG_EXCEPTIONS then
Log(s+' Exception! '+E.ClassName+': '+E.Message, name);
end;

initialization
ThrCS:=TCriticalSection.Create;
finalization
ThrCS.Free;
end.
-----------------------------------------

This unit is part of RealThinClient component package:
www.realthinclient.com

XLog() is for creating daily logs (every day, a new log file), while Log()
is for writing global logs.
By using the "name" parameter, you can use different files for different
parts of your application,
or different kinds of logs: error, warning, information, etc.
This should be simple enough to understand and powerful enough to suit most
apps needs.

Best Regards,
Danijel Tkalcec

"Lauchlan M" <LMackinnonAT_NoSpam_ozemailDOTcomDOTau> wrote

Danijel Tkalcec · Guest

Anyway .. I think that logging mechanisms should be simple enough
to avoid having to log errors that could happen inside the logging routines.

Things like low memory usage (if possible: no HEAP, only stack memory),
fast entry - fast exit (no long-lasting operations),
and no pre-configuration sound like a "must" for general logging.

If you need to log a lot of database-related things,
which is not threatening your application stability,
you could also add a separate logging mechanism to write
database-related stuff inside one or more tables inside a database.

By separating simple file-logging for errors and dabase-logging for
database-stuff,
you won't end up with an error that causes database-writing to fail and not
knowing what happened.

Regards,
Daijel Tkalcec

"Lauchlan M" <LMackinnonAT_NoSpam_ozemailDOTcomDOTau> wrote

Andrea Raimondi · Guest

Lauchlan M wrote:

Matthew Jones · Guest

I use Raize Codesite, which is simply indispensable when working on user
interface code so you can see what is going on "underneath" without having
to do breakpoints which affect the order in which things happen. But it is
also great for remote debugging - you can deploy the capture system, have
it send to file or network machine, and then gather information. Things
that it captures include the app name and thread ID and timestamp, all of
which ensure you are talking about the right information. The viewer adds
extra value in that you can click on two lines and it shows the time
difference between them. It can also categorise, search, and make coffee.

Well worth a look, and buying too.

/Matthew Jones/

Lauchlan M · Guest

Lauchlan M · Guest

Matthew Jones · Guest

Hmm. I sort of see what you want, and agree Codesite does it around the
other way, but it is there and it works. The main thing is that you can
"Send" an object with Codesite, so you could say "Codesite.Send("Current
list", MyListBox);" and the list gets transferred. Basically all the
public properties get sent to the log. Of course you can do this any time
you want, so that could be at exceptions, or whenever you want (or not at
all - the Codesite object becomes "passive" if not enabled).

The advantage that the Codesite way of doing things gives is that you can
output whatever you want whenever you want, and you don't have to
configure something in advance. I can't find a list of the Codesite Object
calls on the Raize website, but
http://www.raize.com/DevTools/CodeSite/Add-Ons/Default.asp has a number of
examples in the templates section. Things like EnterMethod and ExitMethod
allow for some good organisation.

/Matthew Jones/

Paul Dolen · Guest

Uwe Raabe · Guest

Have a look at this one:
www.profscomponents.com/code/Components/Logging/Intro.htm

Lauchlan M · Guest

Lauchlan M · Guest

Doug Olson · Guest

I thought the same thing... nice looking products though.

Doug

"Lauchlan M" <LMackinnonAT_NoSpam_ozemailDOTcomDOTau> wrote

Brian Moelk · Guest

John McTaggart · Guest