Exceptions or logging?

Discussion in 'Java' started by VisionSet, Jun 18, 2004.

  1. VisionSet

    VisionSet Guest

    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?

    --
    Mike W
     
    VisionSet, Jun 18, 2004
    #1
    1. Advertising

  2. VisionSet

    Oscar kind Guest

    VisionSet <> wrote:
    [...]
    > 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

    --
    Oscar Kind http://home.hccnet.nl/okind/
    Software Developer for contact information, see website

    PGP Key fingerprint: 91F3 6C72 F465 5E98 C246 61D9 2C32 8E24 097B B4E2
     
    Oscar kind, Jun 18, 2004
    #2
    1. Advertising

  3. VisionSet

    Chris Uppal Guest

    VisionSet wrote:

    > 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
     
    Chris Uppal, Jun 18, 2004
    #3
  4. VisionSet

    Jacob Guest

    VisionSet wrote:

    > 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.
     
    Jacob, Jun 21, 2004
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Ahmed Moustafa
    Replies:
    5
    Views:
    30,124
    Chris Smith
    Jul 14, 2004
  2. Paul Miller
    Replies:
    3
    Views:
    1,064
    Alex Martelli
    Nov 12, 2003
  3. Jeremy Fincher
    Replies:
    0
    Views:
    314
    Jeremy Fincher
    Dec 2, 2003
  4. Replies:
    3
    Views:
    634
    Sherm Pendley
    Apr 16, 2007
  5. Lie
    Replies:
    3
    Views:
    709
Loading...

Share This Page