5 ms·

I strongly disagree with you. I think too few people use exceptions. They're great for making code more expressive, and it's only through exceptions that you ca

I strongly disagree with you. I think too few people use exceptions. They're great for making code more expressive, and it's only through exceptions that you can avoid two-phase initialization of classes and make constructors actually useful. It's only through exceptions that you can have meaningful copy-constructable resource-holding value types. Avoiding these constructs severely restricts the language. And for what? The arguments against exceptions appear to mostly arise from misunderstanding or some kind of weird aesthetic sense that I don't have. Error codes also generally discard context and encourage a "just abort" mentality, especially with respect to memory exhaustion. That, or they become so general, mechanized, and macro-ized that they might as well be exceptions, but worse in almost every way. Exceptions are your friends.

lasagnaphil 9y ago
About the dependency between constructors and inheritance, I like how rust handled the situation. In rust you do not have any constructors, but instead you can make a factory method that returns an Option<T> or Result<S, E>, so no need for any exceptions while construction. You can also do this in C++, but you still have to declare constructors anyway, along it being a bit inconsistent with other idiomatic C++ code...
- quotemstr 9y ago
  > have to declare constructors anyway At least these days we have class-level initializers to lessen the pain a bit and reduce the number of situations in which you have to write a constructor. struct foo { int bar = 5; };
- jhasse 9y ago
  You can make the constructor private :)
mehrdadn 9y ago
> It's only through exceptions that you can have meaningful copy-constructable resource-holding value types. Could you give an example of this specifically? Are you thinking of e.g. a File class whose constructor opens the file? Because every such example I can think of is one where it ultimately seems inappropriate to me to use exceptions to signal the error. Both from a conceptual standpoint (it might be something you have no control over, so it's not a programmer error) and from a performance standpoint. Example for the latter: say the user gives you a list of hundreds of thousands of files that are to be copied somewhere "if they exist". Imagine half of them don't exist. Now your program is going to have to run through hundreds of thousands of exceptions to signal this.
- AstralStorm 9y ago
  Exceptions are not for handling programmer errors. Assertions are. Exceptions are indeed used for handling exceptional situations such as actual errors. If you only want to copy a file it it exists, then check if it exists (race-prone but fast) or create a function that copies a file only if it exists. Or you know, swallow the nonexistence exception. An optimizing compiler might be able to elide the throw statement if it is inlining the copy function. The only issue seems to be that few people are able to install or create a good top level error handler in case there is an actual unhandled failure.
  - mehrdadn 9y ago
    > Exceptions are not for handling programmer errors. Assertions are. std::logic_error?
    - AstralStorm 9y ago
      That is not a programmer error, this is a domain error mostly for math functions or string parsing. (Other than relatively evil std::length_error/out_of_range which might go either way.) In most cases where it is a bit gratuitously thrown it can be avoided. You might want as well to redefine any error as a programmer error.
      - mehrdadn 9y ago
        > That is not a programmer error, this is a domain error mostly for math functions or string parsing. ....what in the world? no... for domain errors there's, erm, std::domain_error. C++ Reference/StackOverflow/MSDN/etc. already explain all these. But it seems I have to copy-paste them here? "Domain and range errors are both used when dealing with mathematical functions." [1] "std::logic_error reports errors that are a consequence of faulty logic within the program such as violating logical preconditions or class invariants and may be preventable." [2] "std::domain_error may be used by the implementation to report domain errors, that is, situations where the inputs are outside of the domain on which an operation is defined." [3] [1] https://stackoverflow.com/a/641972 https://stackoverflow.com/a/641972 [2] http://en.cppreference.com/w/cpp/error/logic_error http://en.cppreference.com/w/cpp/error/logic_error [3] http://en.cppreference.com/w/cpp/error/domain_error http://en.cppreference.com/w/cpp/error/domain_error
blub 9y ago
As lasagnaphil said, with optional and result types exceptions can be restricted to signaling coding errors instead of any errors. Think vector::at (good) versus std::stoi (bad).
- AstralStorm 9y ago
  What will you do if you do not check if the optional actually has a value? (What happens: you get an exception at the moment of dereference and potentially lose the information about the cause.)
  - steveklabnik 9y ago
    This is true of some languages with these constructs (C++, Scala, AFAIK) but not all (Rust, Haskell). Given that this is a C++ thread, you’re right, but that’s an issue of the particular language, not the idea generally.
  - blub 9y ago
    Actually it's UB by default, so first of all, one should either always use optional::value() or wrap the class. Secondly... yes, that's why exceptions also need good logging/tracing for best results.

lasagnaphil 9y ago

About the dependency between constructors and inheritance, I like how rust handled the situation. In rust you do not have any constructors, but instead you can make a factory method that returns an Option<T> or Result<S, E>, so no need for any exceptions while construction. You can also do this in C++, but you still have to declare constructors anyway, along it being a bit inconsistent with other idiomatic C++ code...

quotemstr 9y ago
> have to declare constructors anyway At least these days we have class-level initializers to lessen the pain a bit and reduce the number of situations in which you have to write a constructor. struct foo { int bar = 5; };
jhasse 9y ago
You can make the constructor private :)

mehrdadn 9y ago

> It's only through exceptions that you can have meaningful copy-constructable resource-holding value types. Could you give an example of this specifically? Are you thinking of e.g. a File class whose constructor opens the file? Because every such example I can think of is one where it ultimately seems inappropriate to me to use exceptions to signal the error. Both from a conceptual standpoint (it might be something you have no control over, so it's not a programmer error) and from a performance standpoint. Example for the latter: say the user gives you a list of hundreds of thousands of files that are to be copied somewhere "if they exist". Imagine half of them don't exist. Now your program is going to have to run through hundreds of thousands of exceptions to signal this.

AstralStorm 9y ago
Exceptions are not for handling programmer errors. Assertions are. Exceptions are indeed used for handling exceptional situations such as actual errors. If you only want to copy a file it it exists, then check if it exists (race-prone but fast) or create a function that copies a file only if it exists. Or you know, swallow the nonexistence exception. An optimizing compiler might be able to elide the throw statement if it is inlining the copy function. The only issue seems to be that few people are able to install or create a good top level error handler in case there is an actual unhandled failure.
- mehrdadn 9y ago
  > Exceptions are not for handling programmer errors. Assertions are. std::logic_error?
  - AstralStorm 9y ago
    That is not a programmer error, this is a domain error mostly for math functions or string parsing. (Other than relatively evil std::length_error/out_of_range which might go either way.) In most cases where it is a bit gratuitously thrown it can be avoided. You might want as well to redefine any error as a programmer error.
    - mehrdadn 9y ago
      > That is not a programmer error, this is a domain error mostly for math functions or string parsing. ....what in the world? no... for domain errors there's, erm, std::domain_error. C++ Reference/StackOverflow/MSDN/etc. already explain all these. But it seems I have to copy-paste them here? "Domain and range errors are both used when dealing with mathematical functions." [1] "std::logic_error reports errors that are a consequence of faulty logic within the program such as violating logical preconditions or class invariants and may be preventable." [2] "std::domain_error may be used by the implementation to report domain errors, that is, situations where the inputs are outside of the domain on which an operation is defined." [3] [1] https://stackoverflow.com/a/641972 https://stackoverflow.com/a/641972 [2] http://en.cppreference.com/w/cpp/error/logic_error http://en.cppreference.com/w/cpp/error/logic_error [3] http://en.cppreference.com/w/cpp/error/domain_error http://en.cppreference.com/w/cpp/error/domain_error

blub 9y ago

As lasagnaphil said, with optional and result types exceptions can be restricted to signaling coding errors instead of any errors. Think vector::at (good) versus std::stoi (bad).

AstralStorm 9y ago
What will you do if you do not check if the optional actually has a value? (What happens: you get an exception at the moment of dereference and potentially lose the information about the cause.)
- steveklabnik 9y ago
  This is true of some languages with these constructs (C++, Scala, AFAIK) but not all (Rust, Haskell). Given that this is a C++ thread, you’re right, but that’s an issue of the particular language, not the idea generally.
- blub 9y ago
  Actually it's UB by default, so first of all, one should either always use optional::value() or wrap the class. Secondly... yes, that's why exceptions also need good logging/tracing for best results.