Maybe it is just misnamed? I have not used Category.assert(), but it seems
like it could be useful. Of course frameworks are often littered with
"useful" but rarely used code.
Rick Hansen
> -----Original Message-----
> From: Ceki Gülcü [mailto:[EMAIL PROTECTED]]
> Sent: Monday, June 25, 2001 11:07 AM
> 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]
