[Issue 5419] exception specifications (but not in Java style)

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=5419


Jonathan M Davis <jmdavisProg at gmx.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jmdavisProg at gmx.com


--- Comment #1 from Jonathan M Davis <jmdavisProg at gmx.com> 2011-01-06 14:17:09 PST ---
C++ does have checks, but they're far worse than nothing. It has throw
specifiers. If you mark a function with throw(LifeHatesMeException), then if
anything other than a LifeHatesMeException is thrown from that function at
runtime, your program will be killed. throw() indicates that nothing may be
thrown from the function. The _only_ time that I think it makes _any_ sense to
use throw specifiers in C++ is throw() on destructors, since having exceptions
thrown from destructors in C++ is serious bad news (unlike D). Java's checked
exceptions are light years better in comparison. It's all compile time checks.

However, I would point out that a large group of programmers have decided that
checked exceptions are just outright a bad idea. The designers of C# decided
that they were a bad idea and didn't include them in C# (
http://blogs.msdn.com/b/csharpfaq/archive/2004/03/12/why-doesn-t-c-have-checked-exceptions.aspx
has some good articles on the matter). Essentially, what it comes down to is
that they _seem_ like a good idea but that practice has shown that they're
highly viral and result in code with stuff like throws Exception on functions,
ultimately making them _less_ safe then they would have been.

D has taken the approach of using nothrow to indicate that no Exception can be
thrown (though an Error can) from a particular function, and that is checked at
compile time. So, you can know whether a particular function can throw
Exception, but you can't know _which_ exceptions it could throw.

I can see why you would want checked exceptions of some kind on library APIs,
but in practice (in Java at least), that generally leads to them all saying
that they throw LibrarySpecificException, which ultimately really isn't useful.
And even if it were determined to be highly desirable to have checked
exceptions on library APIs, to do that, you'd have to have checked exceptions
everwhere, or the compiler couldn't actually guarantee anything. Without
checked exceptions everywhere, the compiler has no prayer of determining
whether the exceptions that you list for a function are indeed the exact set of
exceptions that that function can throw. And if the compiler can't guarantee
that those are the exact exceptions that that function can throw, it's no
better than documentation. And ddoc already can do that. Typically you'd do
something like

/++
    Function description

    Throws:
        FileException
  +/
void func(int a)
{
    ...
}

So, if you can come up with a specific proposal on how we could have checked
exceptions on library APIs without having to use checked exceptions everywhere
like Java does, then it may have a chance of making it in the language. But as
far as I can see, it's all or nothing with checked exceptions. For the compiler
to be able to check them, every function must list them. So, you have them
everywhere. If you don't have them everywhere, then the compiler can't check
them, and so they're just documentation, at which point you might as well just
put them in the actual documentation rather than try and put them in the
function signature.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------