Ceki,
I'd say pull it, I personally disliked the syntax of Category.assert()
method and never used it because I thought it "felt" misleading.
John Volkar
-----Original Message-----
From: Ceki Gülcü [mailto:[EMAIL PROTECTED]]
Sent: Monday, June 25, 2001 12:07 PM
To: LOG4J Users Mailing List
Subject: Re: Category.assert() disappointing
Hello,
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
principle.
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
pointed
>> 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
the
>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
this
>> 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
can
>> be used for other purposes such as throwing a runtime exception. e.g.
>>
>> if (MyCategory.assert( (x==null), "This should never be null" )) throw
new
>> 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
about
>> an extra method such as assertFatal() which will throw the exception for
you
>> 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
existing
>Category.assert function as it stand right now, serve no meaningful
purpose.
>
>>
>> Cheers
>>
>> Simon Liu
>
>ZC
>
>
>>> -----Original Message-----
>>> From: Zart Colwing [SMTP:[EMAIL PROTECTED]]
>>> 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
a
>>> 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:[EMAIL PROTECTED]]
>>>> 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:[EMAIL PROTECTED]
>>>> <mailto:[EMAIL PROTECTED]> ]
>>>>> 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
statement."
>>>>>
>>>>> So I guess I would not have expected it to halt ny application.
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Zart Colwing [ mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> ]
>>>>>> 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: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
--
Ceki Gülcü
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
