[m-dev.] Re: exceptions

[Ralph Becket]

> But my plan involves adding support for dynamic type class casts.
> We will then establish some standard hierarchy of type classes for
> categorizing exceptions.  So it won't be necessary to document
> exactly which types will be thrown, only which categories 
> (type classes)
> they fall into.

Agree so far.

> > Do you plan to have the compiler check things like whether a given
> > exception is caught or not?
> 
> The additional complexity of declaring which exceptions may be thrown
> doesn't seem worth the benefits, IMHO.  

I have to disagree here.  In fact I've just been to a talk where it was
mentioned that some years ago a team from Acorn (remember them?) started
work on a new OS in Modula 2+.  Initially, any exceptions raised by a
procedure were documented by informal discipline, which caused all sorts of
problems when the informal approach went wrong.  So they changed the
compiler
to check that any exceptions that could be raised in the execution of a
given
procedure (and which were not caught by that procedure) were explicitly
declared as part of that procedure's signature.  This caught many many bugs.

>From my own experience, working with a large Prolog system without any
formal
(checked) exception declaration mechanism can be infuriating and a source of
all sorts of runtime bugs.  It's a pain in the bum.

> There are two categories of errors which can occur in _any_ predicate:
> 	- software errors, e.g. calls to error/1
> 	- resource errors, e.g. running out of heap space
> 	  or exceeding a CPU usage time limit
> 
> At very least, those ones should not be declared.
> And if those are not declared, then the benefit in declaring others
> is reduced.

No no no!  I don't have a problem with having to declare which *typeclasses*
of exception a procedure can raise (even if it's just the top-level
typeclass) as long as I know what the failure modes of a given predicate
are.

It may be sensible to leave resource errors implicit, provided they are
reasonably standard.  I certainly want to be able to write code that e.g.
backs off from breadth first search to depth first if the former runs out of
memory.

> Furthermore, the sorts of exceptions which can be thrown is often
> quite dependent on the implementation details of the procedure.

But the typeclass mechanism at least gives you some way of handling this
gracefully.

Ralph
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------