Bug 5419 – exception specifications (but not in Java style)

C++ and Java are two extremes. C++ checks nothing, Java checks everything everywhere. D should stay in the middle and allow compile time checked exception specifications at explicitly specified points (typically functions exported from DLLs). Function anotated by exception specification should not compile unless the compiler can verify it doesn't throw anything unexpected. In C++ there's no way in practice to find out all exceptions a complex code could throw, the proposed feature would allow to eliminate this uncertainty in D code.

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.

I agree with Jonathon.