logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Bushman <...@traxel.com>
Subject Re: LoggingEvent Serialization
Date Tue, 20 Nov 2001 13:00:38 GMT
On Tue, 20 Nov 2001, Ceki Gulcu wrote:

>  My question was actually about the opportunity of calling readFields.
>More like, "how do you know you can call readFields at that point?"


I'm guessing there are several questions here,
so let me take a stab at a few of them (as much
so that I can further understand my motivation
as to explain it):

Q: Why didn't I put the entire contents of
customReadObject inside readObject (which would
guarantee that ois had not already been tampered
with before the call to readFields())?

A: I wanted to keep readObject as much intact as
possible, so that the changes that I had made
would be as obvious as possible. When/if the
change is accepted, I would actually be inclined
to move the contents of customReadObject into
readObject and eliminate customReadObject.

Q: Assuming you were going to keep customReadObject,
Why doesn't it explain in the doc comment that it
requires a "fresh" ObjectInputStream?

A: Because I haven't written the commentary
yet (or rather, haven't written the production
grade commentary). In fact, I might not have
thought to document this requirement if you
hadn't pointed it out, but that's why I support
code audits / peer review (particularly in
infrastructure code like a logging mechanism).

Q: Why do you prefer fine grained methods, even
when it introduces the risk of being passed an
object which is in an unusable state?

A: Because assuming that the method in question
is both private and clearly documented (commentary
is coming :), in my experience more bugs grow in
long methods than in unsafe internal method calls.
When I see a method that's over 50 lines I start
to sweat. If it's so long that I can't see it all
on screen at once, I occasionally run screaming
from the room :)

So the answer is a pragmatic one. Like most
programmers, I would rather be coding than
debugging. One technique that I believe reduces
bugs is fine grained methods, even when they're
not perfectly safe.

There are some other issues that should be
addressed, such as "What if a subclass overrides
an internal method without knowing it?" Declaring
the method final would solve this problem, and
using a more "namespace friendly" name might
make that a more reasonable solution (EG: prefixing
such methods with "le_" to signify that they are
Logging Event internal).

Hmmm, I rather like that last bit. Think I'll
raise that as a discussion topic on my programmers
mailing list....

To unsubscribe, e-mail:   <mailto:log4j-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:log4j-dev-help@jakarta.apache.org>

View raw message