On Fri, 28 Aug 2015 21:25:12 -0500, Ole Ersoy wrote:
On 08/28/2015 04:29 PM, Gilles wrote:
On Fri, 28 Aug 2015 11:48:28 -0500, Ole Ersoy wrote:
This is a side note. In the class Incrementor there's a
MaxCountExceededCallback that triggers the
MaxCountExceededException.
It might make sense to place the code that throws the exception in
a
static utility method inside the exception, eliminating the cb
property, the MaxCountExceededCallback interface, and corresponding
Incrementor constructor. So we could do:
public void incrementCount() throws MaxCountExceededException() {
MaxCountExceededException.throw(++count, max);
}
The callback is intended to let the user choose which action the
counter
exhaustion should trigger. IIRC your proposal, this would not be
possible
anymore.
OK - Got it. I too easily associated the 'MaxCountExceeded' callback
with the MaxCountExceededException. My first thought was that (Even
though the doc says otherwise) if the max is exceeded, then this is
bad, and so an exception should be triggered. How about removing the
MaxCountExceededException
?
The exception could be used independently of the callback interface.
and using a more "Stream" like interface?:
emitter.on('start', cb);
emitter.on('increment', cb);
emitter.on('end', cb);
What would be the gain?
[Seems overkill for the counter functionality as currently used within
CM.]
P.S.
Plus one for "Incrementor(long start, long max).
What do you think of the new API
https://issues.apache.org/jira/browse/MATH-1259
?
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
