On Thu, 24 Sep 2015 22:07:58 -0500, Ole Ersoy wrote:
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.
I would see what makes sense on on case by case basis. For example
if the Observer, which is implemented by the client / person using
CM,
realizes that it can't continue it can throw an application specific
exception using a set of Enums that are coded for the application.
if ( optimizer.yourNeverGonnaGetItEver() ) {
throw new
ApplicationSpecificException(ApplicationErrorCodes.PARTYS_OVER,
optimizer);
}
The error code should be specific enough for the application to
understand the the optimizer argument is the optimizer (Object type),
and then it can construct the message from there.
IMO, we shouldn't force the optimizer instance to hold fields just for
the sake of reporting (the optimizer could make a "CurrentStateReport"
instances on the fly to be passed to the observer at every iteration).
Unless I'm missing something, I don't see the benefit of passing the
optimizer.
All arguments used to instantiate the optimizer must be known already
at the caller's level. The "CurrentStateReport" should only contain
computed values that would allow the caller to decide whether to stop
or continue. In the former case, the caller would be responsible to
merge the initial arguments list and computed values in order to
proceed (e.g. instantiate a new optimizer with the current best model
parameters as initial values).
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).
I would stick with the same process in this case.
?
Regards,
Gilles
Cheers,
- Ole
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
