Okay. I'll proceed with the change. Nick
On Jul 18, 2013, at 2:08 PM, Ralph Goers wrote: > First, I appreciate having the discussion before a code change like this is > made. If that had been done I probably would have vetoed it. But this is the > ASF where everybody gets a single voice and a single vote. Although I dislike > this change and the effect it will have on my users I won't veto it if that > is what the majority wants. > > Ralph > > On Jul 18, 2013, at 11:06 AM, Nick Williams wrote: > >> Hmmm. So it sounds like we're at an impasse. Everyone except Ralph seems to >> agree to renaming it ignoreExceptions, bug Ralph said the below in >> opposition. Ralph, can you clarify a little? Are you objecting to just >> renaming the XML/JSON attribute (which, really, is the only thing that would >> break your teams' configurations)? Or are you objecting to ignoreExceptions >> completely? I can't tell whether you're okay with the isExceptionSuppressed >> method being renamed. >> >> I would just throw it out there that, while I understand that it would be >> inconvenient to have to modify all your configurations, this IS beta >> software. It is not GA yet (hopefully next month or so). Anyone who uses >> beta software does so with the understanding that there could be breaking >> changes before GA. If you didn't want to take that risk, I respectively >> submit that you shouldn't have used beta software in production. I'm not >> saying, "You're wrong." I'm just questioning the motives behind your >> opposition. In short: >> >> If we all agree that ignoreExceptions is a better name that >> suppressExceptions (inconvenience aside), now is the time to change it. We >> can't after GA. >> >> Now I'm not sure how to proceed. :-P >> >> Nick >> >> On Jul 18, 2013, at 1:02 AM, Ralph Goers wrote: >> >>> I do not have a problem with renaming handleExceptions to >>> exceptionSuppressed. I do have a problem with renaming supressExceptions >>> to ignoreExceptions, primarily because I have a bunch of teams using Log4j >>> 2 in production and they would have to modify their configurations when >>> they upgrade. Furthermore, I can't in my wildest dreams imagine anyone >>> getting confused over this parameter and suppressed Throwables. >>> >>> FWIW - handleExceptions means that the Appender "handles" the exception >>> (i.e. it is suppressed). I don't recall why the variables don't match - I >>> think I might have originally exposed "handleExceptions" and found that to >>> be ambiguous and renamed the config param but not the internal variable. >>> >>> Ralph >>> >>> On Jul 17, 2013, at 2:42 PM, Nick Williams wrote: >>> >>>> Appender specifies a method, isExceptionSuppressed(), which indicates >>>> whether exceptions thrown while appending events should be suppressed >>>> (logged instead of re-thrown). >>>> >>>> AbstractAppender implements this method with a private handleExceptions >>>> field and a handleExceptions constructor argument. isExceptionSuppressed() >>>> returns handleExceptions (so, supposedly, "handle exceptions" means "take >>>> care of exceptions instead of the user having to take care of exceptions"). >>>> >>>> Everybody that extends AbstractAppender uses the same handleExceptions >>>> constructor argument. They all define a suppressExceptions XML attribute >>>> that is assigned to the handleExceptions constructor argument in the >>>> static plugin factory method. >>>> >>>> This is all very confusing to me. I just realize that I have misunderstood >>>> "handleExceptions" this whole time in the database appenders and have >>>> assumed it was the opposite of isExceptionSuppressed() / >>>> suppressExceptions (and, thus, have written incorrect code). >>>> >>>> Does anyone have a problem with me renaming handleExceptions to >>>> exceptionSuppressed (to match the JavaBean isExceptionSuppressed method) >>>> to make this less confusing? >>>> >>>> Nick >>>> --------------------------------------------------------------------- >>>> 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] >>> >> >> >> --------------------------------------------------------------------- >> 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
