Comments on: Exception specifications

By: rmn

rmn — Thu, 18 Nov 2010 16:43:59 +0000

That’s true. I have linked Boost’s recommendation against using expcetion specifications in my first comment on this thread as well.

Thanks for posting.

By: Eli

Eli — Thu, 18 Nov 2010 11:33:30 +0000

Keep in mind that Herb Sutter discourages the usage of exception specifications (sources: http://www.gotw.ca/gotw/082.htm and http://www.gotw.ca/publications/mill22.htm). He says the Boost programmers (among whom you find a few people in the C++ standards committee) recommend not using them as well.

By: mike

mike — Wed, 10 Feb 2010 19:03:41 +0000

Technically yes. But there’s a subtle difference. Errors are usually unrecoverable, or require drastic action to fix.

Java, correctly, makes the distinction between these and other situations that are less problematic.

Generally I see many instances where errors have been treated by throwing exceptions. Essentially the programmer is being lazy and saying ‘yeah… I can’t be bothered to deal with this cleanly, so I’ll pass the buck.’ These don’t need exceptions; they need proper error handling!

By: rmn

rmn — Wed, 10 Feb 2010 18:36:54 +0000

I agree!

Just a little note though; Errors are an exception in a way. Errors happen when there’s something not quite right – i.e, when there’s an exception.

By: mike

mike — Wed, 10 Feb 2010 04:29:28 +0000

Actually, the Java enforcement is quite OK.

The problem isn’t the enforcement; it’s the proliferation of exceptions. Exceptions are meant to be just that: exceptions. They’re not meant to be just another way to handle errors.

If people followed this rule, exception handling would be easy.

By: rmn

rmn — Mon, 19 Oct 2009 18:04:30 +0000

I actually can’t stress enough how seriously I dislike the way Java forces you to handle exceptions. You just can’t write a single line of code without making ~5 catch clauses around it, and that basically kills my creativity.
However, I think that documenting code thoroughly is a must in any software project, thus exception specifications can be a very good thing in that they provide this extra documentation (which is even enforced).

By: alon

alon — Fri, 16 Oct 2009 15:01:41 +0000

So you prefer the Java way for enforcing….

By: rmn

rmn — Wed, 07 Oct 2009 14:39:55 +0000

The runtime penalty is more in cases where the function MAY throw, but doesn’t actually (for example when you’re implementing an interface or foreseeing inheritance), and the exception specification actually prevents the compiler from optimizing.
For example, here’s why Boost doesn’t use exception specifications: http://www.boost.org/development/requirements.html#Exception-specification

The solution you suggest (compiler flag) is esentially the same as treating the exceptions you expect to happen and putting an assert(0) on a catch all (catch (…)). Then the assert will be removed on release builds automatically while still providing the needed checking during test phase.

However, I do believe that exception specifications are good as they provide a far better contract (that is also enforced) between the caller and the callee. The problem is in the fact that the enforcement is done in run time and not in compile time.. You would never want your program to terminate with an std::unexpected() in a released version.

By: lorg

lorg — Tue, 06 Oct 2009 20:58:11 +0000

While I like the idea of exception specification, I think it’s too much bureaucracy.
Still, I disagree with your sentiment “which is huge in my eyes, but still not worth the runtime penalty”. What is the runtime penalty? Can you tell? Doesn’t it depend on whether or not the actual application you are developing is time critical?
If it is indeed time critical, the desired behavior I’d want is to be able to have a compiler flag to disable/enable exception specifications.
That way, you can enable them for tests and make sure you never[1] throw unexpected, and disable them for release builds.

[1] as certain as your code coverage by tests allows you to be.