Re: Java exception model. Was: Re: Ada Quality and Style book discussion ("_Type" suffix)

[Brian May <bam@snoopy.apana.org.au>]

>>>>> "Dmitry" == Dmitry A Kazakov <mailbox@dmitry-kazakov.de> writes:

    Dmitry> I think it is reasonable. What Java probably lacks is a
    Dmitry> good way of composition of exception contracts, like "X
    Dmitry> raises what Y does except that ones mentioned in Z."

One issue that is not always clear is how exceptions should be handled
low level routines.

For example, append_mail might be a function that writes a new email
to the users mailbox. Initially the designers decide it might through the
following exceptions:

ERROR_QUOTA_EXCEEDED
ERROR_PERMISSION_DENIED

Later on, the function is expanded to support different formats, e.g.
LMTP, IMAP, etc.

Eventually, one day, a low level routine used by append_mail returns
the exception:

ERROR_OUT_OF_PAPER

What does append_mail do?


It could:

a) return ERROR_OUT_OF_PAPER to calling subroutine, but should the
calling subroutine really have to deal with a printer error? It
doesn't even know the output is going to a printer. Also, should it
really have to deal with network errors? What about LDAP errors,
Kerberos authentication errors, errors creating temporary files, etc?

Yes, it could catch all exceptions, just in case; I am not convinced
this is a good solution.

b) turn the exception into a generic exception for append_mail,
ERROR_APPEND_MAIL, this might make it harder to locate the actual
source of the exception. This I think is my preferred solution, as I
consider the above exceptions private implementation details inside
append_mail, all that the calling function is interested in is the
fact an error occurred, and possibly a string to display to the user
(but see below).

At least with the Java model, the compiler lets you know of the issue,
and you don't suddenly wake up to the fact these low level exceptions
are suddenly being used throughout your entire code.



Then, if the calling process has to generate an error to the sender,
what should the error be?

If I sent an email to somebody and got an error "Out Of Paper", I
think I might be slightly confused. Another alternative is to prefix
the message at each layer, eg:

"Error appending mail: Error sending email via LMTP: Error storing mail: Error logging email: Error writing to syslog: Error writing to printer: Out of paper."

You just need to be able to interpret such a message... I think many
users I know would still be confused, especially as it deals with
technical details specific to the mail setup of the recipient. It
probably would help the administrator though, if he ever receives a
copy of the error.

(yes, you could argue that the above error shouldn't be a fatal error,
lets assume paranoid people).

The other approaches I have seen are hardly worth mentioning:

* generic error for all errors, e.g. "Error!"

* assume error is, say incorrect password, and display verbose
  information on what the user should do to fix an incorrect password.

  (IIRC Outlook does this when accessing a remote IMAP server - and
  the user spends ages trying to work out why the password is wrong
  when the real error is totally unrelated.)
-- 
Brian May <bam@snoopy.apana.org.au>