Re: Using email addresses in exception messages
Le 12/05/2019 à 14:25, Gary Gregory a écrit : > +1 to removing email addresses from exception messages. We should do a pass > over all of Commons. +1, makes sense. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[compress] resource leak in example code
Hi all https://issues.apache.org/jira/browse/COMPRESS-486 highlights a problem of the code inside the example package. The methods with stream or channel arguments create wrapper objects around said streams or channels and never close them. They don't close them because this in turn would close the passed in streams or channels - and that wouldn't seem right as the methods don't own them. One approach I came up with is to add overloads with callbacks that receice the wrapper instance. See https://github.com/apache/commons-compress/commit/5b43a001d151cb7251476e347e19dce480575652 in a branch for what I mean. I toyed with the idea of returning the wrapper object from expand/create but this would still leave the resources unclosed if an exception occured while expanding/creating the archive. An alternative I see is to "simply" close the wrappers ourselves and document the methods will do so. If people need to keep their streams open they must decorate their stream/channel with some NoClose wrappers. Given this is example code I wouldn't feel too bad, even if it breaks backwards compatibility in a way. WDYT? Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Using email addresses in exception messages
+1 to removing email addresses from exception messages. We should do a pass
over all of Commons.
Gary
On Sun, May 12, 2019, 06:46 sebb wrote:
> Some of our code has Exception messages such as the following:
>
> >> (Collections:LRUMap)
> throw new IllegalStateException("Entry.before is null." +
> " Please check that your keys are immutable, and that you have used
> synchronization properly." +
> " If so, then please report this to dev@commons.apache.org as a bug.");
> <<
>
> I guess it seemed like a good idea at the time, but I think the idea
> has backfired:
>
>
> https://lists.apache.org/thread.html/3363e23218b4c1c21b8093321ac293d68d2e4ab35b982adb53b1d5d6@%3Cdev.commons.apache.org%3E
>
> I have seen about 30 of these mails altogether so far.
>
> The intention was for the developer to capture the exception, check
> for the possible programming errors and then inform Commons developers
> if they believe there is a bug.
>
> However it looks like the developers in the case have shown the error
> message direct to end users.
>
> I think the messages (there are quite a lot in Collections, possibly
> elsewhere) should not include an email address. Instead maybe say
> something like:
>
> >>
> throw new IllegalStateException("Entry.before is null." +
> " This should not occur if your keys are immutable, and you have used
> synchronization properly." +
> >>
>
> This would leave it up to the developers to work out how contact us
> once they have eliminated any programming errors. Whilst this is a bit
> more work for the developers, I don't think it's unreasonable to
> expect developers to know how to report bugs in code they are using.
>
> WDYT?
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
Re: Using email addresses in exception messages
> On May 12, 2019, at 6:45 AM, sebb wrote:
>
> Some of our code has Exception messages such as the following:
>
>>> (Collections:LRUMap)
> throw new IllegalStateException("Entry.before is null." +
> " Please check that your keys are immutable, and that you have used
> synchronization properly." +
> " If so, then please report this to dev@commons.apache.org as a bug.");
> <<
>
> I guess it seemed like a good idea at the time, but I think the idea
> has backfired:
>
> https://lists.apache.org/thread.html/3363e23218b4c1c21b8093321ac293d68d2e4ab35b982adb53b1d5d6@%3Cdev.commons.apache.org%3E
>
> I have seen about 30 of these mails altogether so far.
>
> The intention was for the developer to capture the exception, check
> for the possible programming errors and then inform Commons developers
> if they believe there is a bug.
>
> However it looks like the developers in the case have shown the error
> message direct to end users.
>
> I think the messages (there are quite a lot in Collections, possibly
> elsewhere) should not include an email address. Instead maybe say
> something like:
>
>>>
> throw new IllegalStateException("Entry.before is null." +
> " This should not occur if your keys are immutable, and you have used
> synchronization properly." +
>>>
>
> This would leave it up to the developers to work out how contact us
> once they have eliminated any programming errors. Whilst this is a bit
> more work for the developers, I don't think it's unreasonable to
> expect developers to know how to report bugs in code they are using.
>
> WDYT?
I would think that contact information in an error seems to be strange. I would
prefer why the error happened as you suggested.
Hopefully users of our libraries understand how to get in contact with us. But,
given my experience at $work, that’s not always the case.
-Rob
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Using email addresses in exception messages
Some of our code has Exception messages such as the following:
>> (Collections:LRUMap)
throw new IllegalStateException("Entry.before is null." +
" Please check that your keys are immutable, and that you have used
synchronization properly." +
" If so, then please report this to dev@commons.apache.org as a bug.");
<<
I guess it seemed like a good idea at the time, but I think the idea
has backfired:
https://lists.apache.org/thread.html/3363e23218b4c1c21b8093321ac293d68d2e4ab35b982adb53b1d5d6@%3Cdev.commons.apache.org%3E
I have seen about 30 of these mails altogether so far.
The intention was for the developer to capture the exception, check
for the possible programming errors and then inform Commons developers
if they believe there is a bug.
However it looks like the developers in the case have shown the error
message direct to end users.
I think the messages (there are quite a lot in Collections, possibly
elsewhere) should not include an email address. Instead maybe say
something like:
>>
throw new IllegalStateException("Entry.before is null." +
" This should not occur if your keys are immutable, and you have used
synchronization properly." +
>>
This would leave it up to the developers to work out how contact us
once they have eliminated any programming errors. Whilst this is a bit
more work for the developers, I don't think it's unreasonable to
expect developers to know how to report bugs in code they are using.
WDYT?
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [statistics] Mode function for Cauchy distribution
Ok sir. Thanks On Sun, 12 May 2019, 2:39 am Gilles Sadowski, wrote: > Hi. > > Le ven. 10 mai 2019 à 14:45, Udit Arora a écrit : > > > > I am not sure what to say.. I completely agree that most distributions > have > > undefined statistical values. I dont really have any particular reason > for > > adding mode in the interface like one mentioned by Sir Alex for mean and > > variance. Please let me know if I should go ahead.. > > If you don't see a reason, it's reason enough for not doing it. ;-) > > Perhaps a more straightforward way to start contributing is to > browse the list of open issue issues; see e.g. the "Numbers" > project[1]. Help is most needed to progress towards a release, > because "Statistics", and others, depend on it. > > Regards, > Gilles > > [1] > https://issues.apache.org/jira/issues/?jql=project%20%3D%20NUMBERS%20AND%20status%20%3D%20Open > > > > > On Fri, 10 May 2019, 2:15 am Alex Herbert, > wrote: > > > > > > > > > > > > On 9 May 2019, at 21:17, Eric Barnhill > wrote: > > > > > > > > Awesome! > > > > > > > > On Thu, May 9, 2019 at 10:44 AM Udit Arora > > > wrote: > > > > > > > >> I will see what I can do. It will take some time, but I will get to > know > > > >> more about the other distributions. > > > >> > > > >> > > > >> On Thu, 9 May 2019, 10:58 pm Eric Barnhill, > > > > >> wrote: > > > >> > > > >>> Udit, is it clear what to do here? Gilles recommends you propose > some > > > >> edits > > > >>> to ContinuousDistribution instead, to return Mode and Median. > > > >>> > > > >>> But then, if an interface is altered, all the classes that > implement > > > that > > > >>> interface need to have these functions added, so we hope you are > up for > > > >> all > > > >>> that additional work. We can help you. > > > > > > I think it would be prudent to go through all the distributions and see > > > what is defined for each. Wikipedia has a helper table for all its > > > distributions containing: > > > > > > Mean > > > Median > > > Mode > > > Variance > > > Skewness > > > Ex. kurtosis > > > Entropy > > > Fisher Information > > > > > > If many are undefined then you are adding to an interface something not > > > generally supported. > > > > > > Currently the ContinuousDistribution interface only has the mean and > the > > > variance. But note that these are used by the inverse cumulative > > > probability method in the base abstract class. Same goes for the > > > DiscreteDistribution. > > > > > > I am +0 for adding more methods. I don’t see a reason not to. But nor > do I > > > see a need (within the library) to have them at the interface level if > the > > > mode or median for example are not required in a generic way. > > > > > > >>> > > > >>> Last is the idea of accessor methods. if the method starts with > get_() > > > >> then > > > >>> in principle this is just returning a field already present. But > with > > > >> that > > > >>> in mind, I don't know why we already have a method name like > getMean() > > > in > > > >>> this interface. We don't really know whether for a given > distribution, > > > >> that > > > >>> would be a true accessor or need to be calculated. So I think all > these > > > >>> method names should just be mean(), mode(), median(), etc. > > > >>> > > > >>> So sorry if this is blowing up into more work than you expected. It > > > often > > > >>> works that way! I certainly think these changes are worthwhile > however. > > > >>> > > > >>> > > > >>> > > > >>> On Thu, May 9, 2019 at 7:17 AM Gilles Sadowski < > gillese...@gmail.com> > > > >>> wrote: > > > >>> > > > Hi Udit. > > > > > > Le jeu. 9 mai 2019 à 12:52, Udit Arora a > > > >> écrit : > > > > > > > > I intend to add a mode function for the Cauchy Distribution. It > is a > > > small > > > > addition which i thought might be helpful. > > > > > > How will it be helpful? I.e. what would an application developer > > > be able to do, that he can't with the current code? > > > > > > You've surely noted that that the class you want to modify is but > > > one of the implementations of the interface > "ContinuousDistribution". > > > So if you propose to change the API, the change should be done > > > at the interface level, and the appropriate computation > performed, or > > > method overloads defined, for all implementations. > > > > > > The "accessor" methods refer to fields that were set by the > > > contructor; > > > e.g. for "CauchyDistribution", "median" and "scale". > > > In this case, it happens that "mode" has the same value as > "median", > > > but does this warrant an additional method? > > > > > > Regards, > > > Gilles > > > > > > > Thanks > > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > For additional commands, e-mail: dev-h...@commons.apache.org > > >
