3 ms·

You seem to be arguing that, because exception tables end up on separate pages, we should consider exceptions as being as expensive as disk accesses. (Apologies

You seem to be arguing that, because exception tables end up on separate pages, we should consider exceptions as being as expensive as disk accesses. (Apologies if I've just built a straw man, that's how I read it.) I don't buy that. If you use exceptions more than totally exceptionally, according to your definition, then those pages will be loaded to memory and kept there – while the optimisation sounds very clever and sensible, I have a hard time imagining that exception metadata is huge in comparison with the rest of the program code. Once that data is in memory, you're back to the numbers in the article, where throwing an exception can take barely more than a microsecond. That's huge compared to a function call, but is fast compared to a lot of things that an overly cautious programmers wouldn't dare follow up with an exception. To steal your own example, checking whether a file exists certainly falls into this category – that's likely to take milliseconds. (Even your other example – no data available to read (I'm imagining a select / poll situation) – would probably be fine with exceptions, though I agree it's not the right tool for that situation. Just making a call to the OS is likely to cost a comparible amount to throwing an exception, even though you're describing a non blocking call. And by definition this won't end to being called in a critical inner loop - if data becomes available then the exception will do being thrown.)

edoo 7y ago
He makes the point that exceptions should be truly exceptional conditions for your program that would prevent it from running, generally due to system malfunction. Some people use it for basic business logic and it was never meant for that. It is meant to help you gracefully abort things when everything is about to go to hell.
- PaulDavisThe1st 7y ago
  This is not an accurate summary of what C++ exceptions where "meant for". Here's Bjarne in 1989: "The author of a library can detect errors, but does not in general have any idea what to do about them. The user of a library may know how to cope with such errors, but cannot detect them – or else they would have been handled in the user’s code and not left for the library to find. The primary purpose of the exception handling mechanism described here is to cope with this problem for C++ programs; other uses of what has been called exception handling in the literature are considered secondary. See the references for discussions of exception handling techniques and mechanisms."
  - edoo 7y ago
    I think it depends what you consider an error. For example let's say I have a library that opens sockets to hosts. If I can't reach the host that isn't an error and I report back a failure of that function to succeed. If I can't allocate the memory for a socket then instead of reporting a failure to connect I throw an exception for the true error.
- quietbritishjim 7y ago
  > He makes the point that exceptions should be truly exceptional conditions The comment did say that, but the only explanation of why exceptions should only be used that way seemed to be performance based. If that is not the issue, then what is? Saying "that's what they're for" without any other detail is a circular argument.
  - gpderetta 7y ago
    It is a circular argument. I for one I would use exceptions significantly more often if throwing and catching them were to be cheaper (also syntactically). As it is you often end up with both a throwing and optional-returning non-throwing variants of many functions.
  - fefe23 7y ago
    I feel slightly misrepresented. I explained how exceptions are implemented, and the actionable intelligence you can derive from that understanding (if perf matters to your code and/or scenario, then use exceptions only for hard errors, not for generic signaling). If perf does not matter in your scenario, than obviously the guidance does not apply to you. To me that does not mean it's a waste of time to explain how exceptions work and what that means to performance critical code.
fefe23 7y ago
Well it depends on your circumstances. If you care so much about performance in the code path that you do benchmarks to find out how you should be doing your error handling, then you should not be using exceptions. Even if the metadata is loaded after the first time, the error handling code will probably still need to be fetched from disk. Most programs are not performance critical and you can use whatever you want for exception handling. Heck, modern microservice based architectures use message busses and network sockets for error handling. I have seen code signal error conditions by writing things to a database. By the way: Syscalls have become amazingly fast. Some syscalls like gettimeofday are now even done without switching to kernel mode at all. And the raw kernel mode switch is now in the order of hundreds of cycles. I read something like 300 cycles for a modern architecture. Also note that while regular performance is probably not so important, in some areas like hard real-time requirements for automotive or aviation it might still be relevant that your code has a predictable maximum latency.

edoo 7y ago

He makes the point that exceptions should be truly exceptional conditions for your program that would prevent it from running, generally due to system malfunction. Some people use it for basic business logic and it was never meant for that. It is meant to help you gracefully abort things when everything is about to go to hell.

PaulDavisThe1st 7y ago
This is not an accurate summary of what C++ exceptions where "meant for". Here's Bjarne in 1989: "The author of a library can detect errors, but does not in general have any idea what to do about them. The user of a library may know how to cope with such errors, but cannot detect them – or else they would have been handled in the user’s code and not left for the library to find. The primary purpose of the exception handling mechanism described here is to cope with this problem for C++ programs; other uses of what has been called exception handling in the literature are considered secondary. See the references for discussions of exception handling techniques and mechanisms."
- edoo 7y ago
  I think it depends what you consider an error. For example let's say I have a library that opens sockets to hosts. If I can't reach the host that isn't an error and I report back a failure of that function to succeed. If I can't allocate the memory for a socket then instead of reporting a failure to connect I throw an exception for the true error.
quietbritishjim 7y ago
> He makes the point that exceptions should be truly exceptional conditions The comment did say that, but the only explanation of why exceptions should only be used that way seemed to be performance based. If that is not the issue, then what is? Saying "that's what they're for" without any other detail is a circular argument.
- gpderetta 7y ago
  It is a circular argument. I for one I would use exceptions significantly more often if throwing and catching them were to be cheaper (also syntactically). As it is you often end up with both a throwing and optional-returning non-throwing variants of many functions.
- fefe23 7y ago
  I feel slightly misrepresented. I explained how exceptions are implemented, and the actionable intelligence you can derive from that understanding (if perf matters to your code and/or scenario, then use exceptions only for hard errors, not for generic signaling). If perf does not matter in your scenario, than obviously the guidance does not apply to you. To me that does not mean it's a waste of time to explain how exceptions work and what that means to performance critical code.

fefe23 7y ago

Well it depends on your circumstances. If you care so much about performance in the code path that you do benchmarks to find out how you should be doing your error handling, then you should not be using exceptions. Even if the metadata is loaded after the first time, the error handling code will probably still need to be fetched from disk. Most programs are not performance critical and you can use whatever you want for exception handling. Heck, modern microservice based architectures use message busses and network sockets for error handling. I have seen code signal error conditions by writing things to a database. By the way: Syscalls have become amazingly fast. Some syscalls like gettimeofday are now even done without switching to kernel mode at all. And the raw kernel mode switch is now in the order of hundreds of cycles. I read something like 300 cycles for a modern architecture. Also note that while regular performance is probably not so important, in some areas like hard real-time requirements for automotive or aviation it might still be relevant that your code has a predictable maximum latency.