[mercury-users] Exceptions and unique modes

[Paul Massey]

>   From: Fergus Henderson <fjh at cs.mu.OZ.AU>
>
> > On 21-Feb-2001, Peter Ross <peter.ross at miscrit.be> wrote:
> >
> > An interesting point was raised by Paul Massey here at MC, 
> > and that is a predicate should return either a status indicator 
> > or throw an exception but never do both.
>
>   Why not?

In this case basically for maintainability/readability
reasons.

>   In cases where you expect that the immediate caller will
>   typically need to handle certain kinds of results
>   (e.g. EOF), but where you expect that other, exceptional
>   conditions (e.g. I/O errors) will typically need to be
>   handled at a higher level in the application, I think it
>   would be quite reasonable for a predicate to either
>   return a status indicator or throw an exception,
>   depending on which conditions occur.

If you have the following bit of code:
   
   io__open_output("a_file",Res),
   ( { Res = ok(Stream) },
        do_something(Stream,Res1),
	io__close_output(Stream)
   ; { Res = error(Err) },
        report_error(Err) ),
	
Then the code fragment implies to the reader that problems
are trapped and reported. If io__open_output or whatever
then throws an exception as well as returns an error code
then the error handling here is for nothing (having to wrap
a try_io and error code handling around each io__open_output
is somethings which would be more than a bit ugly and
totally unreadable). Note: do_something is the same and
returns an error code as well. However, if it now throws an
exception as well then the above code is unsafe since the
io__close_output wouldn't always get called.

In the server we have developed error reporting and logging
of those errors is present to try to provide sufficient
"contextual" information for us to track down a problem
after it has occurred (maybe days after the problem was
first noticed). So the error handling needs to log as much
information as possible about the context of the error to
aid in tracking it down. The biggest problem with the
current exception system is that a backtrace isn't attached
to the exception which can be accessed once it is trapped
(ie. context, etc. is pretty much lost). I'm told .Net could
possibly provide this type of feature.

>  In many cases, especially with higher-order code or code
>  using type classes, it naturally arises that a procedure
>  will return a status indicator of some kind, but code
>  which it can invoke via a higher-order call or a class
>  method call may throw an exception that it won't know how
>  to deal with, and must propagate to the caller.

We've had problems with that as well and basically because
of the above - I was trapping error codes and closing the
db/file correctly based on an error (but then the code was
modified and an exception was thrown in one situation). This
change rended my error handling code useless/insuffient and
I didn't even know it (until the exception got thrown), thus
leaving the db connection open.

There are situations when exceptions are useful, but mixing
the two modes of reporting problems means the code becomes
difficult to maintain and understand.

Paul.

--------------------------------------------------------------------------
mercury-users mailing list
post:  mercury-users at cs.mu.oz.au
administrative address: owner-mercury-users at cs.mu.oz.au
unsubscribe: Address: mercury-users-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-users-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------