[mercury-users] exceptions and cc_multi
fjh at cs.mu.OZ.AU
Sat Dec 2 11:13:43 AEDT 2000
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?!? ;-)
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
More information about the users