Live data from Hacker News

Real cost of C++ exception vs error-code checking

lazarenko.me

1–10 of 64 posts

Re: Real cost of C++ exception vs error-code checking

#3
Today with terabyte harddrives, gigabytes of RAM and broadband connections, when is the binary size a more important factor than both execution speed and ease of development? Especially when the binary size difference is probably not huge?

Shouldn't the advice of this article just be "use exceptions"?

Re: Real cost of C++ exception vs error-code checking

#5

Today with terabyte harddrives, gigabytes of RAM and broadband connections, when is the binary size a more important factor than both execution speed and ease of development? Especially when the binary size difference is probably not huge? Shouldn't the advice of this article just be "use exceptions"?

Not all development targets desktops or laptops.

Re: Real cost of C++ exception vs error-code checking

#6
post #2

I prefer Raymond Chen's take on exceptions: http://blogs.msdn.com/b/oldnewthing/archive/2005/01/14/35294...

"since you have to check every single line of code (indeed, every sub-expression) and think about what exceptions it might raise and how your code will react to it"

Yes, that's my concern with exceptions as well. It seems like the Java model (if I remember it right -- it's been a decade), which requires a method to either handle an exception that a sub-method throws or explicitly allow it to be thrown, would be preferable and help people avoid accidentally ignoring an exception.

I'd like to see support for exceptions like this in C++0X, but I haven't bothered to check to see if it's there...

Re: Real cost of C++ exception vs error-code checking

#7
post #2

I prefer Raymond Chen's take on exceptions: http://blogs.msdn.com/b/oldnewthing/archive/2005/01/14/35294...

This reads to me like 'writing good code is hard, and writing even better code is even harder'. With modern C++0x smart pointers (like unique_ptr) and RAII, you can get very high performance and (more) easily exception-safe code. Maybe a lot of C++ exception criticism comes from people still trying to code like C in C++?

Re: Real cost of C++ exception vs error-code checking

#8

Today with terabyte harddrives, gigabytes of RAM and broadband connections, when is the binary size a more important factor than both execution speed and ease of development? Especially when the binary size difference is probably not huge? Shouldn't the advice of this article just be "use exceptions"?

Cache sizes have not seen gains proportional to RAM or HDs.

Re: Real cost of C++ exception vs error-code checking

#9
post #2

I prefer Raymond Chen's take on exceptions: http://blogs.msdn.com/b/oldnewthing/archive/2005/01/14/35294...

"since you have to check every single line of code (indeed, every sub-expression) and think about what exceptions it might raise and how your code will react to it" Yes, that's my concern with exceptions as well. It seems like the Java model (if I remember it right -- it's been a decade), which requires a method to either handle an exception that a sub-method throws or explicitly allow it to be thrown, would be prefe…

You're thinking of "checked exceptions" and C++ already has them (pre 0X) via the "throws" clause on method declarations.

Checked exceptions is a hotly debatted topic and I think the world has kinda finally come around to deciding that the are a bad idea overall. Google it and see for yourself.

Re: Real cost of C++ exception vs error-code checking

#10

Today with terabyte harddrives, gigabytes of RAM and broadband connections, when is the binary size a more important factor than both execution speed and ease of development? Especially when the binary size difference is probably not huge? Shouldn't the advice of this article just be "use exceptions"?

when is the binary size a more important factor than both execution speed and ease of development?

Binary size (or maybe more accurately in this case, binary code layout) can be highly relevant for speed due to the instruction cache.

As for ease of development, there are issues with C++ exceptions regarding this as well: some C++ libraries aren't exception safe, and neither are practically all C libraries. This is something you need to worry about whenever you pass a function pointer into a library, as there might be an exception-unsafe function higher up in the stack. Propagating an exception up through it is potentially extremely dangerous.

That said, using exceptions can still be a good idea, especially if your code doesn't need to be portable or if you know the platforms in advance, and you are careful about passing around function pointers. All you need to do is ensure that any of your code that might be called from third-party code with questionable exception semantics won't throw or propagate any exceptions, e.g. by installing a catch-all exception handler in it.

Post reply on HN