3 ms·

The point is not that you're handling an exception with some function, it's that knowing which function is being called to handle the exception becomes difficul

The point is not that you're handling an exception with some function, it's that knowing which function is being called to handle the exception becomes difficult to reason about. This is the relevant line in the article: > The problem with that is that you have no idea of who and where is going to handle the exception. If you don't have a try/catch immediately around the throw, say at a higher level of where the function was called or, in the "worst" case, in the main body block, then the handling becomes hard to reason about. I believe the argument is that reasoning about who handles which exception when is difficult and putting in logic to handle each individual exception at a higher level increases program complexity. Further, hunting back through the code to which piece of parent call handles the exception becomes increasingly difficult, especially if a function is called at different points with their own try/catch blocks. The problem compounds because if you use classes, then there's no way to get around using exceptions as that's the only way to communicate that a constructor has failed. This means if you wanted to abandon C++ exceptions in favor of C-style error handling but still wanted to use classes, you would now need to mix and match C-style error handling with C++ style exception handling. I don't quite see the argument against the class/struct <list> issue and I agree that this, from what I can tell, could be worked around and has better alternatives in C++ than they're making arguments against.

jamier1978 4y ago
To me the two bits of code in the error handling case or not comparable. In the c++ case you would still handle the error in the if statement if it can be handled otherwise you would throw it. C++ has the advantages of giving you both options.
arinlen 4y ago
> The problem with that is that you have no idea of who and where is going to handle the exception. I don't buy the argument. By design exception handlers are handlers of exceptional events, which due to their exceptional nature either lead to a controlled recovery or controlled exit. Once you're faced with your personal need to care enough about specific types of exceptions to the point they are no longer exceptional but a common occurrence, you're already mishandling exceptions at a fundamental level. Consequently the solution is to not handle these expected cases as exceptions, or at most add try-catch next to the potential source of these commonly-occurring exceptions and don't let them leak beyond their source. Exceptions are a kin to fire alarms and exception-handling is a kin to an organized evacuation plan. If you're misusing the fire alarm to the point you're complaining that you pull a particular fire alarm so often during your normal workflow that you start complaining you can't track badges during emergency evacuations, you should take a step back and take a long hard look at what you're doing, and how you're misusing that safety feature.
- abetusk 4y ago
  I don't really know what to say. It's not that you're wrong or couldn't' be right, it's that there's a whole ecosystem of language and tooling, culture of idiomatic program design and human psychology at play. So you draw a line in the sand and say that using exceptions for cases where errors are commonplace is fundamentally misunderstanding. Is this true for every library you use? For every programmer you're going to hire? For every scenario that you're going to encounter? Maybe, but it's asserting what reality should look like rather than what it actually is. Arguments about which programming to use on a philosophical level are always hard because it's, in my opinion, effectively a psychological argument. The language provides intrinsics that allow you to think about problems in a certain way and use tools to help express ideas within that framework succinctly. So saying "this is a fundamental misunderstanding of what this intrinsic is there for" is kind of besides the point. How is it used? Does it's presence in the language make sense to use it in the way you think it should be used? I actually don't have a big opinion on this, I was mostly trying to "strongman" the argument so that a better discussion could be had. I will point out that many more "modern" languages, like Go (and Rust?) use the more C-like error handling than the try/catch type error handling.
  - arinlen 4y ago
    > I don't really know what to say. It's not that you're wrong or couldn't' be right, it's that there's a whole ecosystem of language and tooling, culture of idiomatic program design and human psychology at play. It seems you wanted to say that there are frameworks out there that use exception handling to handle flow control. There are indeed. There's also plenty of fundamentally broken code around. That is not a justification to perpetuate mistakes. It's like someone complaining that sticking fingers in power outlets hurts because of the jolt. Well, then don't?
  - zasdffaa 4y ago
    Exceptions are typically understood to apply to exceptional events that just shouldn't happen. The only language I know of that treats them as control structures is Python (ok, lisp as well come to think of, but they seem to be very different things from C++ exceptions. I have no experience with these). > Arguments about which programming to use on a philosophical level are always hard because it's, in my opinion, effectively a psychological argument If you treat them other than language convention expects, maybe that's a problem. I have read up on the original exception designs and talked to the originator of these (Brian someone, I can't remember his surname). I believe I'm not misrepresenting him to say that he looked on exceptions as 'should never happen' events. However they have come to be seen as treating errors a bit more forgivingly (eg. network dropped) so in some cases a fresh attempt can be made. That seems reasonable. As others have said, they're your last ditch attempt at doing something sensible, or perhaps trying to recover, when the impossible happens, so sqrt(-1) is an exception. Excepting because of a failure of a user to log in is not (true: that comes from a dr. dobbs article). This is a good discussion https://en.wikipedia.org/wiki/Exception_(computer_science) https://en.wikipedia.org/wiki/Exception_(computer_science).
jcelerier 4y ago
> If you don't have a try/catch immediately around the throw, say at a higher level of where the function was called or, in the "worst" case, in the main body block, then the handling becomes hard to reason about. what exactly do you call "hard to reason about" ? if it's an exception most likely the library itself has no business handling it and should just let it propagate to the user of the library.
- Brian_K_White 4y ago
  I don't want to be the user of a library that might do something even the library itself doesn't know why it happened. Your point seems to be that any exeption that makes it to the top must by simple definition of reaching that point, have been something the user did or in some other way "not my problem", which I think is ridiculous. The whole article starts with the assertion that they want this library to be solid not slapdash.

jamier1978 4y ago

To me the two bits of code in the error handling case or not comparable. In the c++ case you would still handle the error in the if statement if it can be handled otherwise you would throw it. C++ has the advantages of giving you both options.

arinlen 4y ago

> The problem with that is that you have no idea of who and where is going to handle the exception. I don't buy the argument. By design exception handlers are handlers of exceptional events, which due to their exceptional nature either lead to a controlled recovery or controlled exit. Once you're faced with your personal need to care enough about specific types of exceptions to the point they are no longer exceptional but a common occurrence, you're already mishandling exceptions at a fundamental level. Consequently the solution is to not handle these expected cases as exceptions, or at most add try-catch next to the potential source of these commonly-occurring exceptions and don't let them leak beyond their source. Exceptions are a kin to fire alarms and exception-handling is a kin to an organized evacuation plan. If you're misusing the fire alarm to the point you're complaining that you pull a particular fire alarm so often during your normal workflow that you start complaining you can't track badges during emergency evacuations, you should take a step back and take a long hard look at what you're doing, and how you're misusing that safety feature.

abetusk 4y ago
I don't really know what to say. It's not that you're wrong or couldn't' be right, it's that there's a whole ecosystem of language and tooling, culture of idiomatic program design and human psychology at play. So you draw a line in the sand and say that using exceptions for cases where errors are commonplace is fundamentally misunderstanding. Is this true for every library you use? For every programmer you're going to hire? For every scenario that you're going to encounter? Maybe, but it's asserting what reality should look like rather than what it actually is. Arguments about which programming to use on a philosophical level are always hard because it's, in my opinion, effectively a psychological argument. The language provides intrinsics that allow you to think about problems in a certain way and use tools to help express ideas within that framework succinctly. So saying "this is a fundamental misunderstanding of what this intrinsic is there for" is kind of besides the point. How is it used? Does it's presence in the language make sense to use it in the way you think it should be used? I actually don't have a big opinion on this, I was mostly trying to "strongman" the argument so that a better discussion could be had. I will point out that many more "modern" languages, like Go (and Rust?) use the more C-like error handling than the try/catch type error handling.
- arinlen 4y ago
  > I don't really know what to say. It's not that you're wrong or couldn't' be right, it's that there's a whole ecosystem of language and tooling, culture of idiomatic program design and human psychology at play. It seems you wanted to say that there are frameworks out there that use exception handling to handle flow control. There are indeed. There's also plenty of fundamentally broken code around. That is not a justification to perpetuate mistakes. It's like someone complaining that sticking fingers in power outlets hurts because of the jolt. Well, then don't?
- zasdffaa 4y ago
  Exceptions are typically understood to apply to exceptional events that just shouldn't happen. The only language I know of that treats them as control structures is Python (ok, lisp as well come to think of, but they seem to be very different things from C++ exceptions. I have no experience with these). > Arguments about which programming to use on a philosophical level are always hard because it's, in my opinion, effectively a psychological argument If you treat them other than language convention expects, maybe that's a problem. I have read up on the original exception designs and talked to the originator of these (Brian someone, I can't remember his surname). I believe I'm not misrepresenting him to say that he looked on exceptions as 'should never happen' events. However they have come to be seen as treating errors a bit more forgivingly (eg. network dropped) so in some cases a fresh attempt can be made. That seems reasonable. As others have said, they're your last ditch attempt at doing something sensible, or perhaps trying to recover, when the impossible happens, so sqrt(-1) is an exception. Excepting because of a failure of a user to log in is not (true: that comes from a dr. dobbs article). This is a good discussion https://en.wikipedia.org/wiki/Exception_(computer_science) https://en.wikipedia.org/wiki/Exception_(computer_science).

jcelerier 4y ago

> If you don't have a try/catch immediately around the throw, say at a higher level of where the function was called or, in the "worst" case, in the main body block, then the handling becomes hard to reason about. what exactly do you call "hard to reason about" ? if it's an exception most likely the library itself has no business handling it and should just let it propagate to the user of the library.

Brian_K_White 4y ago
I don't want to be the user of a library that might do something even the library itself doesn't know why it happened. Your point seems to be that any exeption that makes it to the top must by simple definition of reaching that point, have been something the user did or in some other way "not my problem", which I think is ridiculous. The whole article starts with the assertion that they want this library to be solid not slapdash.