3 ms·

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 structure

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).

abetusk 4y ago
Doing a quick Google search, I see a paper by Stroustrup that looks to support your argument [0]. From the paper: > One aspect of the exception handling scheme ... is that the default response to an error ... is to terminate the program. While that may have been the intent, I'm arguing that how it's used is not that in modern C++. For example, the constructor for `ifstream` throws an exception when encountering a problem trying to open a file [1]. There are many cases where this wouldn't fall under your definition of "exceptions should lead to termination". Whether this is "proper" C++ standard library ideology or not is beside the point. This is built into the language, used in a standard library and guiding programmers into an idiomatic way of using exceptions as error handling. I imagine the C++ STL is rife with this type of idiom. I'm really not a big fan of "you should read the article" type of arguments, especially when the article contradicts the point. From the Wikipedia article you link to, here some quotes that support my thesis: > Kiniry writes that "As any Java programmer knows, the volume of try catch code in a typical Java application is sometimes larger than the comparable code necessary for explicit formal parameter and return value checking in other languages that do not have checked exceptions. ..." > Exception handling is often not handled correctly in software, especially when there are multiple sources of exceptions; data flow analysis of 5 million lines of Java code found over 1300 exception handling defects. > ... Weimer and Necula wrote ... that they "create hidden control-flow paths that are difficult for programmers to reason about". These mostly relate to Java-style try/catch issues but I suspect they're at least somewhat valid for C++. Again, I'm trying to make a good-faith argument. I see many situations where exceptions as understood by yourself and Stroustrup can lead to better quality code but I'm trying to highlight what the original article was talking about and try to see it from their point of view. As with almost all of these arguments, there's an "it depends" clause. The arguments against exceptions in the article has an implicit "it depends on the context of creating my MQ library". The arguments in the comments are arguing against it without providing the necessary context. [0] https://www.stroustrup.com/except89.pdf https://www.stroustrup.com/except89.pdf [1] https://en.cppreference.com/w/cpp/io/basic_ios/exceptions https://en.cppreference.com/w/cpp/io/basic_ios/exceptions
- zasdffaa 4y ago
  This is getting badly OT and I don't know how we got here. My original top post was saying if you don't need exceptions, why are you using them. They weren't necessary there so they should not have been used there. That is all. In this I am sure we agree.

abetusk 4y ago

Doing a quick Google search, I see a paper by Stroustrup that looks to support your argument [0]. From the paper: > One aspect of the exception handling scheme ... is that the default response to an error ... is to terminate the program. While that may have been the intent, I'm arguing that how it's used is not that in modern C++. For example, the constructor for `ifstream` throws an exception when encountering a problem trying to open a file [1]. There are many cases where this wouldn't fall under your definition of "exceptions should lead to termination". Whether this is "proper" C++ standard library ideology or not is beside the point. This is built into the language, used in a standard library and guiding programmers into an idiomatic way of using exceptions as error handling. I imagine the C++ STL is rife with this type of idiom. I'm really not a big fan of "you should read the article" type of arguments, especially when the article contradicts the point. From the Wikipedia article you link to, here some quotes that support my thesis: > Kiniry writes that "As any Java programmer knows, the volume of try catch code in a typical Java application is sometimes larger than the comparable code necessary for explicit formal parameter and return value checking in other languages that do not have checked exceptions. ..." > Exception handling is often not handled correctly in software, especially when there are multiple sources of exceptions; data flow analysis of 5 million lines of Java code found over 1300 exception handling defects. > ... Weimer and Necula wrote ... that they "create hidden control-flow paths that are difficult for programmers to reason about". These mostly relate to Java-style try/catch issues but I suspect they're at least somewhat valid for C++. Again, I'm trying to make a good-faith argument. I see many situations where exceptions as understood by yourself and Stroustrup can lead to better quality code but I'm trying to highlight what the original article was talking about and try to see it from their point of view. As with almost all of these arguments, there's an "it depends" clause. The arguments against exceptions in the article has an implicit "it depends on the context of creating my MQ library". The arguments in the comments are arguing against it without providing the necessary context. [0] https://www.stroustrup.com/except89.pdf https://www.stroustrup.com/except89.pdf [1] https://en.cppreference.com/w/cpp/io/basic_ios/exceptions https://en.cppreference.com/w/cpp/io/basic_ios/exceptions

zasdffaa 4y ago
This is getting badly OT and I don't know how we got here. My original top post was saying if you don't need exceptions, why are you using them. They weren't necessary there so they should not have been used there. That is all. In this I am sure we agree.