You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Henri Yandell <fl...@gmail.com> on 2011/07/27 08:42:02 UTC
[lang] LANG-686 Recursive call of replaceEachRepeatedly
I'm wondering what people think to:
https://issues.apache.org/jira/browse/LANG-686
I've improved the message of the thrown exception to match the
javadoc, but I'm wondering if a TTL of 2 to protect a
StackOverflowError is really necessary :) I have the urge to throw in
64, or 512, or some random number as a minimum value, but unsure.
Alternatively, we could just let the StackOverflowError happen and
remove the TTL code.
Thoughts?
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang] LANG-686 Recursive call of replaceEachRepeatedly
Posted by Henri Yandell <fl...@gmail.com>.
On Sat, Jul 30, 2011 at 2:27 AM, Henri Yandell <fl...@gmail.com> wrote:
> On Fri, Jul 29, 2011 at 8:27 AM, Gary Gregory <ga...@gmail.com> wrote:
>> Hi Hen,
>>
>> I am not really comfortable knowing that a SOE can be a "normal" code
>> path. It would have to be Javadoc'd to boot.
>>
>> I can see catching IllegalStateException and IllegalArgumentException
>> in client code, especially in a server or a processor of some kind,
>> but to do that for SOE feels wrong. An SOE would crash a server based
>> a client request for example.
>
> Any thoughts on how to define an arbitrary number of loops to allow?
> Throwing an ISE (or IAE) to protect against SOE when it's a loop of 2
> is a bit aggressive :)
>
>> I think I'd rather keep the exception. Also I think it should be an
>> IAE instead of an ISE because the problem is that the arguments are
>> bad and the SU class does have state.
>
> I think it used to be an IAE. The javadoc definitely was.
>
> Easy to change back.
Looking at the history of the code, I think it's always been an ISE
with an IAE listed in the javadoc. Additionally array lengths have
thrown an IAE and declared a IndexOutOfBoundsException. Lovely :)
For now my intention is to fix the javadoc and improve the exception
method and discuss other changes later.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang] LANG-686 Recursive call of replaceEachRepeatedly
Posted by Henri Yandell <fl...@gmail.com>.
On Fri, Jul 29, 2011 at 8:27 AM, Gary Gregory <ga...@gmail.com> wrote:
> Hi Hen,
>
> I am not really comfortable knowing that a SOE can be a "normal" code
> path. It would have to be Javadoc'd to boot.
>
> I can see catching IllegalStateException and IllegalArgumentException
> in client code, especially in a server or a processor of some kind,
> but to do that for SOE feels wrong. An SOE would crash a server based
> a client request for example.
Any thoughts on how to define an arbitrary number of loops to allow?
Throwing an ISE (or IAE) to protect against SOE when it's a loop of 2
is a bit aggressive :)
> I think I'd rather keep the exception. Also I think it should be an
> IAE instead of an ISE because the problem is that the arguments are
> bad and the SU class does have state.
I think it used to be an IAE. The javadoc definitely was.
Easy to change back.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang] LANG-686 Recursive call of replaceEachRepeatedly
Posted by Gary Gregory <ga...@gmail.com>.
Hi Hen,
I am not really comfortable knowing that a SOE can be a "normal" code
path. It would have to be Javadoc'd to boot.
I can see catching IllegalStateException and IllegalArgumentException
in client code, especially in a server or a processor of some kind,
but to do that for SOE feels wrong. An SOE would crash a server based
a client request for example.
I think I'd rather keep the exception. Also I think it should be an
IAE instead of an ISE because the problem is that the arguments are
bad and the SU class does have state.
Gary
On Thu, Jul 28, 2011 at 6:26 PM, Henri Yandell <fl...@gmail.com> wrote:
> Anyone against just letting users get a StackOverflowError?
>
> https://issues.apache.org/jira/browse/LANG-686
>
> Hen
>
> On Tue, Jul 26, 2011 at 11:42 PM, Henri Yandell <fl...@gmail.com> wrote:
>> I'm wondering what people think to:
>>
>> https://issues.apache.org/jira/browse/LANG-686
>>
>> I've improved the message of the thrown exception to match the
>> javadoc, but I'm wondering if a TTL of 2 to protect a
>> StackOverflowError is really necessary :) I have the urge to throw in
>> 64, or 512, or some random number as a minimum value, but unsure.
>>
>> Alternatively, we could just let the StackOverflowError happen and
>> remove the TTL code.
>>
>> Thoughts?
>>
>> Hen
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
Thank you,
Gary
http://garygregory.wordpress.com/
http://garygregory.com/
http://people.apache.org/~ggregory/
http://twitter.com/GaryGregory
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang] LANG-686 Recursive call of replaceEachRepeatedly
Posted by Henri Yandell <fl...@gmail.com>.
Anyone against just letting users get a StackOverflowError?
https://issues.apache.org/jira/browse/LANG-686
Hen
On Tue, Jul 26, 2011 at 11:42 PM, Henri Yandell <fl...@gmail.com> wrote:
> I'm wondering what people think to:
>
> https://issues.apache.org/jira/browse/LANG-686
>
> I've improved the message of the thrown exception to match the
> javadoc, but I'm wondering if a TTL of 2 to protect a
> StackOverflowError is really necessary :) I have the urge to throw in
> 64, or 512, or some random number as a minimum value, but unsure.
>
> Alternatively, we could just let the StackOverflowError happen and
> remove the TTL code.
>
> Thoughts?
>
> Hen
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org