5 ms·

I find this analysis strange. Yes, C++ does need ergonomic ways to return an error without dynamic allocation (Rust's magic of ? combined with the From/Into tra

by ziml77 5y ago

I find this analysis strange. Yes, C++ does need ergonomic ways to return an error without dynamic allocation (Rust's magic of ? combined with the From/Into traits is nice), but I don't know why you'd analyze the performance impact when you have many failures. If a failure is that common, then you aren't supposed to be using exceptions. It's not really an exceptional circumstance at that point.

masklinn 5y ago
> I don't know why you'd analyze the performance impact when you have many failures. If a failure is that common, then you aren't supposed to be using exceptions. The problem is in that case you get into a probabilistic estimation, which is a nice way to say you roll the dice on your performances: what’s the ratio at which exceptions are too costly or sufficiently cheap? And how does that impact your level of service if e.g. exceptions are extremely rare but they tend to all affect the same request or workload?
- HelloNurse 5y ago
  If the program fails too often or too unfairly, why should you blame how such failures are handled? The only reasonable "probabilistic estimation" is that something that happens 10% of the time is normal and it shouldn't be treated as an "exception", even if actually thrown exceptions were fast.
  - masklinn 5y ago
    > If the program fails too often or too unfairly, why should you blame how such failures are handled? Because the discussion is about methods of reporting and handling failure? > The only reasonable "probabilistic estimation" is that something that happens 10% of the time is normal and it shouldn't be treated as an "exception" That makes no sense whatsoever, and doesn't address the question. And even if a ctor fails at a rate of 0.9, it has to report errors via exceptions, because that's the only mechanism available to ctors.
    - im3w1l 5y ago
      You could use an output pointer parameter. You could construct an object which self-reports as invalid. You could take an error handler callback. You could use a global variable. Or I think my preference would be a private constructor, and a friend-function that returns value-or-error.
- xrikcus 5y ago
  Adding to that once exceptions start being thrown, that ratio changes because the cost is so high. It's not hard for a service to reach a failure rate just high enough that it overwhelms the system.
tneumann 5y ago
That argument is only true in single threaded applications, at least given today's exception implementations. The more threads you have, the more problematic exceptions become. On the large machine you start to see performance problems with 0.1% failure rate, which is not that much. An core counts continue to rise.
- PaulDavisThe1st 5y ago
  Again, most experienced C++ programmers would say that even a 0.1% "normal" failure rate indicates a situation that should not be handled by exceptions. You seem to be describing a style of programming where there's a bunch of work to be done, most efforts to do the work will succeed, a few will predictably (albeit randomly, perhaps) fail. While I would concede that you might conclude that exceptions are the perfect tool to use to deal with the failures... 1) you're describing a fairly unusual application behavior 2) it's only because of the performance goals that the speed of exceptions matters I'm the lead dev of a cross-platform DAW where our "inner loop" is real-time constrained by hardware. We use exceptions freely (in a multicore, multithreaded context) with no performance issues, because if they ever happen, things must stop.
  - lanstin 5y ago
    True but also libraries and people thinking differently. Numeric is not real-time, tho it has many common characteristics.
  - olvy0 5y ago
    I do the same. I reserve exceptions for a really exceptional situations. My motto is that if an exception happens, the program should crash since it's an unrecoverable error. That's just my opinion by I try to enforce that in my own codebase. My main beef with exceptions is that sneak past the type system. Unlike Java with its exception specification, in C++ we have no idea what to catch. Yes, there's documentation, but it's often hard to keep it in sync with the code. I've been bitten many times in the last couple of years by surprising exceptions jumping from deep inside innocent function calls, either because of a deep dependency or because someone just threw one and didn't document it (that someone was also a younger me on occasion...) So my design criteria for exception is, is this error here unrecoverable for the application? The 2 examples in OP's paper are 2 functions, and we have no context. If they were a part, say, of a console application that was used in a nightly cron job, and there was no user to ask for proper input, then yes, maybe crashing the application is acceptable. I would still have liked to print something to a log. If this was a part of an interactive program, then a proper error code / std::optional / other error object about the illegal value and its place in the array should be returned, with a proper error message displayed to the user about logged. This I'd do by having a top-level catch handler. A single one for all the application.
JAlexoid 5y ago
Errors and exceptions aren't necessarily low in all cases. And in any case this is about how these exceptions impact parallel processing - and the impact is not negligible.
CJefferson 5y ago
Why am I "not supposed to use exceptions"? I don't understand why exception should be used when errors occur occasionally, or when they occur 50,000/sec. They are a control flow method for when errors occur.
- jcelerier 5y ago
  > . They are a control flow method for when errors occur. no, not any errors, exceptional errors. Input data coming from "outside" being invalid is not exceptional. The filesystem suddenly becoming inaccessible during a copying or caching operation, the OS not being able to join a thread, your logging backend becoming unable to log because the disk is full, or a regular expression being incorrect are what comes to mind when I think of exceptional situations (unless your program allows users to input regexps). If your program runs on a normal computer in normal conditions, no exceptions should ever be thrown.
- MauranKilom 5y ago
  For the same reason you may want to use or not use memory allocations when doing something 1 time per second or 1 million times per second. Performance is not amenable to arguments about degree (especially when talking about this many orders of magnitude in degree).
  - gpderetta 5y ago
    But again, the question is whether exceptions need to be slow. If I'm writing a string_to_int function today I would return an optional<int> (or some Either variant). But if exceptions were cheap I would use them. If I'm catching an exception in the context of immediate caller and the compiler inlines the calle, it ought to be able to optimise the exceptional path away. But it doesn't happen.
- michaelnik 5y ago
  I'd add a (major) inconvenience is problem investigation, often exceptions point you to root cause and all you need it to break on the first exception (think after running big codebase, for an 1h just to get where problem is), but if they are thrown willy-nilly this debugging strategy is MUCH less convenient...

by ziml77 5y ago

masklinn 5y ago

> I don't know why you'd analyze the performance impact when you have many failures. If a failure is that common, then you aren't supposed to be using exceptions. The problem is in that case you get into a probabilistic estimation, which is a nice way to say you roll the dice on your performances: what’s the ratio at which exceptions are too costly or sufficiently cheap? And how does that impact your level of service if e.g. exceptions are extremely rare but they tend to all affect the same request or workload?

HelloNurse 5y ago
If the program fails too often or too unfairly, why should you blame how such failures are handled? The only reasonable "probabilistic estimation" is that something that happens 10% of the time is normal and it shouldn't be treated as an "exception", even if actually thrown exceptions were fast.
- masklinn 5y ago
  > If the program fails too often or too unfairly, why should you blame how such failures are handled? Because the discussion is about methods of reporting and handling failure? > The only reasonable "probabilistic estimation" is that something that happens 10% of the time is normal and it shouldn't be treated as an "exception" That makes no sense whatsoever, and doesn't address the question. And even if a ctor fails at a rate of 0.9, it has to report errors via exceptions, because that's the only mechanism available to ctors.
  - im3w1l 5y ago
    You could use an output pointer parameter. You could construct an object which self-reports as invalid. You could take an error handler callback. You could use a global variable. Or I think my preference would be a private constructor, and a friend-function that returns value-or-error.
xrikcus 5y ago
Adding to that once exceptions start being thrown, that ratio changes because the cost is so high. It's not hard for a service to reach a failure rate just high enough that it overwhelms the system.

tneumann 5y ago

That argument is only true in single threaded applications, at least given today's exception implementations. The more threads you have, the more problematic exceptions become. On the large machine you start to see performance problems with 0.1% failure rate, which is not that much. An core counts continue to rise.

PaulDavisThe1st 5y ago
Again, most experienced C++ programmers would say that even a 0.1% "normal" failure rate indicates a situation that should not be handled by exceptions. You seem to be describing a style of programming where there's a bunch of work to be done, most efforts to do the work will succeed, a few will predictably (albeit randomly, perhaps) fail. While I would concede that you might conclude that exceptions are the perfect tool to use to deal with the failures... 1) you're describing a fairly unusual application behavior 2) it's only because of the performance goals that the speed of exceptions matters I'm the lead dev of a cross-platform DAW where our "inner loop" is real-time constrained by hardware. We use exceptions freely (in a multicore, multithreaded context) with no performance issues, because if they ever happen, things must stop.
- lanstin 5y ago
  True but also libraries and people thinking differently. Numeric is not real-time, tho it has many common characteristics.
- olvy0 5y ago
  I do the same. I reserve exceptions for a really exceptional situations. My motto is that if an exception happens, the program should crash since it's an unrecoverable error. That's just my opinion by I try to enforce that in my own codebase. My main beef with exceptions is that sneak past the type system. Unlike Java with its exception specification, in C++ we have no idea what to catch. Yes, there's documentation, but it's often hard to keep it in sync with the code. I've been bitten many times in the last couple of years by surprising exceptions jumping from deep inside innocent function calls, either because of a deep dependency or because someone just threw one and didn't document it (that someone was also a younger me on occasion...) So my design criteria for exception is, is this error here unrecoverable for the application? The 2 examples in OP's paper are 2 functions, and we have no context. If they were a part, say, of a console application that was used in a nightly cron job, and there was no user to ask for proper input, then yes, maybe crashing the application is acceptable. I would still have liked to print something to a log. If this was a part of an interactive program, then a proper error code / std::optional / other error object about the illegal value and its place in the array should be returned, with a proper error message displayed to the user about logged. This I'd do by having a top-level catch handler. A single one for all the application.

JAlexoid 5y ago

Errors and exceptions aren't necessarily low in all cases. And in any case this is about how these exceptions impact parallel processing - and the impact is not negligible.

CJefferson 5y ago

Why am I "not supposed to use exceptions"? I don't understand why exception should be used when errors occur occasionally, or when they occur 50,000/sec. They are a control flow method for when errors occur.

jcelerier 5y ago
> . They are a control flow method for when errors occur. no, not any errors, exceptional errors. Input data coming from "outside" being invalid is not exceptional. The filesystem suddenly becoming inaccessible during a copying or caching operation, the OS not being able to join a thread, your logging backend becoming unable to log because the disk is full, or a regular expression being incorrect are what comes to mind when I think of exceptional situations (unless your program allows users to input regexps). If your program runs on a normal computer in normal conditions, no exceptions should ever be thrown.
MauranKilom 5y ago
For the same reason you may want to use or not use memory allocations when doing something 1 time per second or 1 million times per second. Performance is not amenable to arguments about degree (especially when talking about this many orders of magnitude in degree).
- gpderetta 5y ago
  But again, the question is whether exceptions need to be slow. If I'm writing a string_to_int function today I would return an optional<int> (or some Either variant). But if exceptions were cheap I would use them. If I'm catching an exception in the context of immediate caller and the compiler inlines the calle, it ought to be able to optimise the exceptional path away. But it doesn't happen.
michaelnik 5y ago
I'd add a (major) inconvenience is problem investigation, often exceptions point you to root cause and all you need it to break on the first exception (think after running big codebase, for an 1h just to get where problem is), but if they are thrown willy-nilly this debugging strategy is MUCH less convenient...