Exceptions or logging?

[VisionSet]

I set up my model with one call from the view: getModel()
This instantiates the model if one is not present, singleton fashion.

The instantiation retrieves various files and processes a lot of try catch
IOExceptions. One case is the single call to create a Properties object,
which I have wrapped.

properties = new MyProperties();

This looks for an exisiting file, validates it and creates a whole new file
or just ammends single properties for any failed validations.

I need to pass any problems back to the view to notify the user, even if
they have been handled nicely.

If my new MyProperties() throws an exception, I won't have an object.

An alternative is to set a 'problems' attribute in MyProperties and query it
after instantiation.

Then throw a new exception from Model() constructor.

Or is exceptions not the way to go at all, and I should catch everything as
I am doing and build a log StringBuffer or something to pass to the user?

The exceptions that are thrown I consider truely exceptional, all will be
fine if the admin user sets up a bad file after the 1st run, since
MyProperties corrects the situation.

What is the best way to approach this requirement?

 

[Oscar kind]

If my new MyProperties() throws an exception, I won't have an object.

An alternative is to set a 'problems' attribute in MyProperties and query it
after instantiation.

An error code (maybe implemented as a message in a StringBuffer) is better
suited for situations where errors are normal (for example when validating
user input). I prefer them is such a case because exception handling is a
bit slow. This is OK when there's an exceptional situation, but not
otherwise.

Then throw a new exception from Model() constructor.

Throwing an exception after evaluating an error code (or catching an
exception and generating an error code) is always a bad idea: use either
exceptions or error codes.


[...]

The exceptions that are thrown I consider truely exceptional, all will be
fine if the admin user sets up a bad file after the 1st run, since
MyProperties corrects the situation.

What is the best way to approach this requirement?

Exceptions are exceptionally suited for this kind of error reporting
(pardon the pun). The reason is that errors should not occur in this case.

Exceptions tell the programmer what went wrong where, and almost always
signal a programming error, configuration problem or a network issue.
Also, I've never come across an exception one can recover from and still
perform the required operation.


kind regards,
Oscar

 

[Chris Uppal]

I set up my model with one call from the view: getModel()
This instantiates the model if one is not present, singleton fashion.

The instantiation retrieves various files and processes a lot of try catch
IOExceptions. One case is the single call to create a Properties object,
which I have wrapped.

properties = new MyProperties();

This looks for an exisiting file, validates it and creates a whole new
file or just ammends single properties for any failed validations.

I need to pass any problems back to the view to notify the user, even if
they have been handled nicely.

This doesn't sound like a proper application of (externally visible) exceptions
to me. A thrown exception means "for some reason, this operation could not
complete normally", not "something odd happened, but don't worry it's all
sorted now".

It might be worth thinking about a variation on the Observer pattern, where
interested clients can register to be told about any "odd" events, and then
they can log it, or abort the app, or send email to the board of directors, or
whatever.

In practise, however, I suspect that nobody really /needs/ to know,
immediately, that something /could/ have gone wrong, but has in fact been
fixed. In which case, just log it and forget it...

-- chris

 

[Jacob]

What is the best way to approach this requirement?

This is a classic MVC setup, where the I/O module
is the "View" part, your model is the "Model" and
the managing code which triggers the I/O operation
and builds the model is the "Controller".

What you should do is to report I/O anomlaies
through a logging interface, i.e. you should catch I/O
exception from your I/O module and report them using
the logger. The controller should act as the supervisor
(i.e. implement the interface) and should catch
logging messages. This object is the only one capable
of putting an error into *context*, i.e. to understand
how fatal each error is relative to the overall model
build process.