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?

Cheers,
- Ole


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Reply via email to