On Thu, 24 Sep 2015 18:01:13 -0500, Ole Ersoy wrote:
On 09/24/2015 04:05 PM, Gilles wrote:
On Thu, 24 Sep 2015 08:43:38 -0500, Ole Ersoy wrote:
On 09/24/2015 06:31 AM, luc wrote:
Le 2015-09-24 04:16, Ole Ersoy a écrit :
On 09/23/2015 03:09 PM, Luc Maisonobe wrote:
CM is not intended to be a design pattern people should mimic.
We are so bad at this it would be a shame. No one in its right
mind would copy or reuse this stuff. It is for internal use only
and we don't even have the resources to manage it by ourselves so
we can't consider it as a path people should follow as we are
leading them. Here we would be leading them directly against the
wall.
Hehe - I think that's like Michael Jordan saying - "Guys, don't
try to
be like me. I just play a little ball. Dunk from the free throw
line. Six world championships, but THATs it!". In any case, I
really
appreciate you and Gilles taking the time to talk. Luc (And
possibly
Gilles) - I can actually see why you are getting a bit annoyed,
because I'm ignoring something important.
I've been doing 90% NodeJS stuff lately (Which is event loop
based and
relies callbacks) so I forgot one very important thing that I
think
you have both tried to tell me. The exception undoes the current
callstack / breaks the current program flow, bubbling up to the
handler. Thaaaats a good point.
OK - So scratch the callback thinking for synchronous code. The
Lombok stuff should still be good though and hopefully some of
the
callback discussion around and asynchronous option - I hope!
Geez.
What do you think about having one exception per class with an
Enum
that encodes the various types of exceptional conditions that the
class can find itself in? So in the case of
LevenbergMarquardtOptimizer there would be a:
- LevenbergMarquardtOptimizerException:
- LevenbergMarquardtOptimizerExceptionEnum
When the exception is thrown it sets the Enum indicating the root
cause. The enum can then be used as a key to lookup the
corresponding
message.
Any better?
Sure. I would suggest adding some parameters to help the upper
level formatting
a meaningful message (say the number of iterations performed if
you hit a max
iteration, so users become aware they should have set the limit
higher). Nothing
over-engineered, a simple Object[] that can be used as last
argument to something
like String.format() would be enough.
Brilliant - I'll setup a repository and start experimenting. Thanks
again,
- Ole
I don't understand what Luc proposed.
But just having "Object[]" mentioned makes me shiver... :-{
Thanks to the "ExceptionContext" it is readily possible to add as
many "messages"
as we want to be displayed. [There is no need to ask the caller to
use "format()"
as it is done in CM.]
And there are also a methods for setting and getting an "Object".
I'd be for using more (possibly "local") exceptions if we want to
convey
more, and more specific, information. This should be done with
getters that
return typed information, not "Object"s.
Javascripters do what Luc is advocating all the time, so I'm used to
it.
If the exception is specific to the class throwing the exception then
we could attach a reference to the instance throwing the exception
and
use Lombok to generate binary getters.
Why should the instance throwing the exception hold a field with the
information? Separation of concerns: optimizer does the computation,
then the exception holds what's needed for a full report of the
failure.
Or the report is done at the observer's level, based on complete
information routinely returned by the optimizer at every step (cf.
previous mail).
Gilles
Cheers,
- Ole
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
