[m-dev.] checked exceptions.

Matt Giuca matt.giuca at gmail.com
Wed Feb 13 13:54:22 AEDT 2013

It sounds like Mercury DU-based sorts errors are supposed to be used for
predictable or expectable exceptions, like "file not found". This is the
equivalent of Java checked exceptions. In other words, these represent
"normal" conditions (but not necessarily good conditions).

The risky unexpected exceptions, or the ones that should never happen but
could theoretically happen anywhere, such as divide by zero, that's what
exceptions in Mercury can be used for; they're effectively "program broke"
errors, so there is no need to catch them. This is the equivalent of Java's
unchecked exceptions. In other words, the current model is fine, but people
need to use it properly.
On 13 Feb 2013 13:42, "Paul Bone" <paul at bone.id.au> wrote:

> On Wed, Feb 13, 2013 at 01:10:31PM +1100, Michael Day wrote:
> > Hi Paul,
> >
> >> How do people feel about checked exceptions?
> >
> > Vehemently opposed :)
> >
> > In my opinion the use of discriminated union types for return values is
> > one of the strong points of Mercury programming, and checked exceptions
> > would undermine that.
> >
> > Since it would be a new complex addition to the type system, it needs a
> > very strong motivation to justify adding it.
> >
> > What is the reason for considering this feature?
> I'm glad you asked in this way.
> Because not everone uses DU types the way they _should_ be used.  So if we
> have DU types people should use them and shouldn't need these types of
> exceptions.
> Between your e-mail and Micheal Richter's e-mail I'm thinking that
> something
> more like ocamlexp is the right way to go.
> --
> Paul Bone
> http://www.bone.id.au
> _______________________________________________
> developers mailing list
> developers at lists.mercurylang.org
> http://lists.mercurylang.org/listinfo/developers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurylang.org/archives/developers/attachments/20130213/1d8b5789/attachment.html>

More information about the developers mailing list