----------------------------------------- (on vwall2) email-body was scanned and no virus found ---------------------------------------------------------
After looking at the code I would have to agree with you. Mark Russell PNC 412-768-9603 Ceki Gülcü <[EMAIL PROTECTED]> To: "LOG4J Users Mailing List" <[EMAIL PROTECTED]> cc: 06/25/2001 Subject: Re: Category.assert() disappointing 12:07 PM Please respond to "LOG4J Users Mailing List" ----------------------------------------- (on vwall2) email-body was scanned and no virus found --------------------------------------------------------- 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]