Prev: return to the begin of InputStream
Next: array concatenation problem
From: Mike Schilling on 3 Dec 2009 16:16
Martin Gregorie wrote:
> An even better trick I learned from an ancient OS (ICL George 3) is
> to
> leave tracing permanently active but to send it to a circular
> buffer.
> Dumping the buffer is triggered by fatal errors, so you get the
> error
> plus the program actions leading to it. The overhead of this
> approach
> is a bit higher, but again not really noticeable. The benefit is
> that
> you are guaranteed to get a manageable amount of diagnostics from
> any
> crash.


Very nice.


From: Tom Anderson on 4 Dec 2009 16:34
On Wed, 2 Dec 2009, Arne Vajh?j wrote:

> Martin Gregorie wrote:
>
>> I have never got on with debuggers, so I tend to load up my programs
>> with trace statements that output to stderr. So far, so conventional,
>> however I also add command line options to control debugging detail by
>> setting a 'debug' integer and always leave this stuff in production
>> code because the speed impact of testing integer values and skipping
>> debug statements is minimal and the diagnostic value of this trick
>> during live running is huge.
>
> I completely agree that debuggers are great for debugging toy programs,
> but log output is often much better for real world programs.

I think they're for completely different purposes. Logging is for figuring
out roughly where an problem is - your application is behaving badly, so
you have a look at the logs , and you see warnings suggesting something's
wrong in the furnace or whatever. A debugger is for figuring out why a
component is causing a problem - you attach to the furnace and fire
various inputs at it and follow execution, and see where invariants are
violated, where the wrong branch is being taken, where nulls are creeping
in, etc.

I find i get a lot more use out of the debugger early on in development,
when i'm actually writing something and its internal behaviour is still in
flux. Later on, when things are more about integration and discovering
corner cases, it's often "hmm, i see the turntable is crashing when i load
colours with a lot of blue in them - oh yeah, i only allowed forty bytes
for blue, that's what it is", and you don't even need to look hard at the
code or debug to figure out the solution.

tom

--
If goods don't cross borders, troops will. -- Fr
From: Arne Vajhøj on 4 Dec 2009 19:37
Mike Schilling wrote:
> Arne Vajh�j wrote:
>> But I would use log4j instead of something home made.
>
> Why log4j rather than java.util.logger? (just curious; I've always
> used the latter, so have no basis for comparison)

log4j has more features than jul.

And if it is a Java EE context then log4j are most likely already
there, so I want the de luxe solution.

If it is an Java SE context then I would consider jul to simplify
deployment.

Arne
From: Mike Schilling on 5 Dec 2009 00:10
Arne Vajh�j wrote:
> Mike Schilling wrote:
>> Arne Vajh�j wrote:
>>> But I would use log4j instead of something home made.
>>
>> Why log4j rather than java.util.logger? (just curious; I've always
>> used the latter, so have no basis for comparison)
>
> log4j has more features than jul.

Which ones do you find most useful?


From: Arne Vajhøj on 2 Jan 2010 21:34
On 04-12-2009 16:34, Tom Anderson wrote:
> On Wed, 2 Dec 2009, Arne Vajh?j wrote:
>> Martin Gregorie wrote:
>>> I have never got on with debuggers, so I tend to load up my programs
>>> with trace statements that output to stderr. So far, so conventional,
>>> however I also add command line options to control debugging detail
>>> by setting a 'debug' integer and always leave this stuff in
>>> production code because the speed impact of testing integer values
>>> and skipping debug statements is minimal and the diagnostic value of
>>> this trick during live running is huge.
>>
>> I completely agree that debuggers are great for debugging toy
>> programs, but log output is often much better for real world programs.
>
> I think they're for completely different purposes. Logging is for
> figuring out roughly where an problem is - your application is behaving
> badly, so you have a look at the logs , and you see warnings suggesting
> something's wrong in the furnace or whatever. A debugger is for figuring
> out why a component is causing a problem - you attach to the furnace and
> fire various inputs at it and follow execution, and see where invariants
> are violated, where the wrong branch is being taken, where nulls are
> creeping in, etc.
>
> I find i get a lot more use out of the debugger early on in development,
> when i'm actually writing something and its internal behaviour is still
> in flux. Later on, when things are more about integration and
> discovering corner cases, it's often "hmm, i see the turntable is
> crashing when i load colours with a lot of blue in them - oh yeah, i
> only allowed forty bytes for blue, that's what it is", and you don't
> even need to look hard at the code or debug to figure out the solution.

In my experience then if a debugger can be used to find the problem
then reading the code can do it.

Arne

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: return to the begin of InputStream
Next: array concatenation problem