[mercury-users] exceptions and cc_multi

[Fergus Henderson]

On 01-Dec-2000, Renaud Paquay at MC <rpa at miscrit.be> wrote:
> 
> I totally agree that a Mercury implementation needs to take exception
> into account, and use them for, at least, all "low-level technical 
> problem" (out of memory, out of any resource), because that is needed
> for the type of application we write (multi-user application server):
> We simply cannot "bomb out" when an "out of memory" condition occurs.
>
> So, if I understand you well, that means, with an "exception safe" 
> implementation of Mercury, all predicates will be "cc_multi" (since
> any predicate could throw an exception), and "det" won't
> exist anymore (except for the trivial "true", I suppose).

Nope.  Throwing an exception doesn't make things cc_multi.
Only catching exceptions makes things cc_multi.

Saying that something is `det' means that *if* it returns normally,
it will return exactly one solution.  Saying that something is
`det' does not guarantee that the procedure will terminate,
or that it will not throw an exception, and if the procedure
does throw an exception, saying that it is `det' does not
guarantee anything about which exception(s) will be thrown.

> I totally agree. In Java (sorry for this :-), there are two types of
> exceptions: "Throwable", which do not need explicit annotation and
> handling, and "Error", which needs explicit handling or annotation.
> (I'm not sure about the class names, but that's the idea).
> 
> I've not really made my mind if this is really helpful, or a pain,
> because I've not much experience with it.

Yes, I know how Java does it, but like you I don't have much exerience
with it.  However, even if it is helpful in Java, that doesn't
necessarily mean that we should adopt the same solution in Mercury.
There are a couple of important differences between Mercury and Java
in this respect; one is that Mercury allows code reordering, and
Java doesn't, while the other is that Mercury has better support
for discriminated union types (see below).

> ... there may be cases where explicit exception specification
> might be useful ...
> However, in such cases, it may also be as practical as defining the
> computation result as a "maybe" type or "ok/error" union type.

I agree.  Furthermore using a discriminated union type like this has
the advantage that things stay `det' rather than becoming `cc_multi',
so in most cases it is probably a better solution. 

Hence I don't think it is worth complicating the Mercury language with
support for exception specifications.

> Another problem I have with Mercury exception is they are of any 
> type. That is excactly the same problem as with C++: it is almost 
> impossible to write a "generic" exception handler, because the set 
> of exception types changes depending on what libraries are 
> (directly or indirectly) used. So, having exception of any type is 
> also a "break" the code re-use (in the exception handler, 
> in that case).
> 
> I like the idea of Java (sorry again) of having a root 
> exception class, with at least a "Message" member. That forces 
> the programmer to add a message whenever he throws an exception. 
> When debugging a server, that is really a good thing to have 
> a message written by the programmer, because it is supposed to 
> describe what exactly happened. Note that it can be done without
> an explicit message, but that means 10 programmers will throw
> 10 different types of exceptions, and most of them won't even
> bother adding an descriptive error message in it.
> 
> However, this issue is less a problem with Mercury, because 
> it is always possible to get the textual representation 
> of any term (using the term module, if I remember well).
>
> We could anyway define an exception as a typeclass with a 
> "get_message" predicate, and enforcing any "throw" predicate 
> to throw a instance of the "exception" (or derived) typeclass.

I agree, that's a very good idea.

`io__write(univ_value(Exception))' is what the Mercury
standard library uses to report uncaught exceptions.
But the result looks like a Mercury term, not a message
of the kind appropriate for a user to see.

> PS: I know it is probably a sin to use "Java" in a Mercury 
>     mailing list.

Not at all.  How are we supposed to figure out how to beat
the competitors if we can't even discuss them?!? ;-)

Cheers,
	Fergus.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
                                    |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------