logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Johan Karlsson TACMa <j...@tac.se>
Subject RE: Category.assert() disappointing
Date Tue, 26 Jun 2001 06:32:14 GMT
Hi Ceki!

I agree! Deprecate the assert() method and use Log4j only as a logging


-----Original Message-----
From: Ceki Gülcü [mailto:cgu@qos.ch]
Sent: den 25 juni 2001 18:07
To: LOG4J Users Mailing List
Subject: Re: Category.assert() disappointing


Log4j is a logging library. As such, it does not have the mandate to halt
the hosting application. What you are requesting goes against this basic

The Category.assert() method was added over a year ago. At that time, we
went through a similar discussion and it was agreed to have
Category.assert() log an error message but not abort. During those 12+
months, this is the first time that I hear a complaint about the issue. This
does not mean you are wrong but derision is definitely unwarranted.

I think it was a mistake to add Category.assert because 

1) It does not abort as many people would expect it.
2) log4j is a logging library.

At this stage I am inclined to first deprecate and then remove
Category.assert() unless someone finds it useful and actually uses it *as
is*. For reasons that are not hard to imagine, it is out of question to
change the existing non-abort behavior.

Regards, Ceki

At 18:18 22.06.2001 +0200, you wrote:
>> Zart, it's a good idea to log failed assertions.  I agree that the method
>> name assert() implies that it is an assertion mechanism, though as
>> out, it doesn't claim to do anything more than log to error based on
>> true/false.
>I just wrote this code this morning in the Airline Traffic Controller
>program we are working on public void alertCollision(String message) with
>the following javadoc comment /** assign message to the global variable
>gUserAlert. The controller will be alerted once he setup a watchpoint on
>global variable gUserAlert with gdb */
>I think the maintenance team will have a very good time with this one !
>> Sorry, can't give a better explanation for the method's existence.
>Ceki, any explanations ?
>> We can easily add logging to our own assertion classes... or if we want
>> into log4j, perhaps Ceki could change the behaviour of the assert method,
>> for example:
>> boolean Category.assert( boolean assertion, msg );
>> The method should return the boolean value of the assertion, so that it
>> be used for other purposes such as throwing a runtime exception. e.g.
>> if (MyCategory.assert( (x==null), "This should never be null" )) throw
>> RuntimeException("blah blah");
>> However it seems to be a bit of pain to type out the message again, so
>> perhaps the assert() method should take on more responsibility.  How
>> an extra method such as assertFatal() which will throw the exception for
>> and log to fatal?
>> MyCategory.assertFatal( (x==null), "see you!");
>Exactly my thoughts, except that I would rather re-implement the existing
>Category.assert function instead of creating a new one, because the
>Category.assert function as it stand right now, serve no meaningful
>> Cheers
>> Simon Liu
>>> -----Original Message-----
>>> From:    Zart Colwing [SMTP:zartc@mac.com]
>>> Sent:    Thursday, June 21, 2001 10:51 PM
>>> To:    LOG4J Users Mailing List
>>> Subject:    Re: Category.assert() disappointing
>>>> Is a logging framework where you want to implement an assertion
>>> mechanism?
>>> Why not ?  There is no assert mechanism in Java (except manually testing
>>> condition and throwing a RuntimeException); having one implemented in
>>> log4j
>>> doesn't seems a bad idea at first glance.
>>> But the point is org.apache.log4j.Category.assert() is NOT an assert
>>> mechanism despite its name. Either it is a misnomer or it is badly
>>> implemented.
>>> That's why I asked what is the purpose of this assert function.
>>> Is there someone that is using it ?
>>> ZC
>>>> -----Original Message-----
>>>> From: Gino Marckx [mailto:gmarckx@reference.be]
>>>> Sent: Thursday, June 21, 2001 8:57 AM
>>>> To: 'LOG4J Users Mailing List'
>>>> Subject: RE: Category.assert() disappointing
>>>> But shouldn't it in fact be FATAL and quit?
>>>> I think Zart has a point...  At least the logging level should be
>>> FATAL...
>>>> Gino. 
>>>>> -----Original Message-----
>>>>> From: Hansen, Richard [ mailto:Richard.Hansen@westgroup.com
>>>> <mailto:Richard.Hansen@westgroup.com> ]
>>>>> Sent: Thursday, June 21, 2001 3:53 PM
>>>>> To: 'LOG4J Users Mailing List'
>>>>> Subject: RE: Category.assert() disappointing
>>>>> Here is what the javadoc says about Category.assert():
>>>>> "If assertion parameter is false, then logs msg as an error
>>>>> So I guess I would not have expected it to halt ny application.
>>>>>> -----Original Message-----
>>>>>> From: Zart Colwing [ mailto:zartc@mac.com <mailto:zartc@mac.com>
>>>>>> Sent: Thursday, June 21, 2001 8:16 AM
>>>>>> To: LOG4J Users Mailing List
>>>>>> Subject: Category.assert() disappointing
>>>>>> I'm disappointed by the Category.assert() function.
>>>>>> It was my belief that when an assert breaks that means that
>>>>>> the conditions
>>>>>> for the safe continuation of the program execution are not
>>>>>> meet and it is
>>>>>> better to halt the program right away before running into big
>>>>>> troubles. 
>>>>>> Category.assert() obviously doesn't live by the same
>>>>>> interpretation because
>>>>>> it never tries to halt the faulty program in any way, shape or form.
>>>>>> For me Category.assert() is just a way to log at ERROR level,
>>>>>> not even at 
>>>>>> FATAL level as one could at least expect !
>>>>>> I'm just asking if it is intentional and if yes why so ?
>>>>>> Tanks 
>>>>>> ZC 
>To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: log4j-user-help@jakarta.apache.org

Ceki Gülcü

To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-user-help@jakarta.apache.org

To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-user-help@jakarta.apache.org

View raw message