5 ms·

You realise you can just unwrap an optional after checking it’s not nullopt, right?

jcelerier 5y ago
Not if it's part of the state of your app ? E.g. a struct member. It also replaces an automated and enforced action by the compiler (exception being thrown) by a need for a manual check which feels very 1975
- Thorrez 5y ago
  >Not if it's part of the state of your app ? E.g. a struct member. I'm not sure what you mean. Here's an example with the output from std::optional being unwrapped and put in a struct member: https://godbolt.org/z/Ms4Kar18j https://godbolt.org/z/Ms4Kar18j Also there's opt.value_or() which can use a default value in the case opt is nullopt. >It also replaces an automated and enforced action by the compiler (exception being thrown) by a need for a manual check which feels very 1975 I think remram's goal was to avoid exceptions. So this is a criticism of remram's goal rather than the method to achieve that goal. Also, std::optional can integrate with exception-producing code because opt.value() throws an exception if opt is nullopt.
  - jcelerier 5y ago
    > I'm not sure what you mean. Here's an example with the output from std::optional being unwrapped and put in a struct member: https://godbolt.org/z/Ms4Kar18j https://godbolt.org/z/Ms4Kar18j And now you have to do this for every type that have some amount of preconditions. I don't understand in which universe this is sane - more code == more bugs. e.g. here's what one would write with exceptions: https://godbolt.org/z/evMsh6383 https://godbolt.org/z/evMsh6383 (and, to be honest, if one is writing e.g. a command-line tool and not a reactive gui app, most likely https://godbolt.org/z/eW8YM5Gz4 https://godbolt.org/z/eW8YM5Gz4 as your OS will catch the thing anyways and then it's just a `coredumpctl gdb` / "open in debugger" away) ; you get the same guarantee of never having an invalid Foo but at much less mental cost. It also prevents you of having aggregates as all the "parent" owner class will need their own wrapping in optional + private ctor, in case a sub-sub-sub-sub field would fail. e.g. given struct DomainObject { Foo mainFoo; Foo secondaryFoo; int whatever; }; struct GameState { std::vector<DomainObject> objects; }; now you can't just do DomainObject{initForMainFoo, initForSecondaryFoo, 123}; or DomainObject{.mainFoo = "", .secondaryFoo = "", .whatever = 123}; anymore, even less GameState{{DomainObject{...}, DomainObject{...}}; which is how modern C++ is meant to be used
    - pkolaczk 5y ago
      Exception handling may indeed end up with less code, but often it is because the developers forgot to handle most error situations properly. And that's my biggest gripe with exceptions, particularly the unchecked ones, which can just pop up from 100 layers below. I've just seen it too many times when developers just throw exceptions and let them bubble up to a place where there is so little context that the final error message presented to the user is near useless. On the other hand return values (using something like a try/either monad) have the property of forcing the developer to think about the unhappy path in every layer. Maybe a bit more code, but the quality of diagnostics - priceless. IMHO exceptions/panics should be reserved for bugs only (eg assertions), and return values for all the other error handling caused by user input or environment.
      - jcelerier 5y ago
        > I've just seen it too many times when developers just throw exceptions and let them bubble up but it's the whole point ! that's exactly why exceptions are good ! > to a place where there is so little context that the final error message presented to the user is near useless. there are only two valid cases: there's an error that you know you are able to recover from, you did recover, and the users does not see a message and never knows that an error happened, OR the user sees the message "The program has encountered an error. A backup of your data has been saved in c:/foo/. The program will now exit.". Anything else makes software terrible to use. If you have logging and recovery to do, use your logging architecture and core dumps, don't misuse exceptions for that. > On the other hand return values (using something like a try/either monad) have the property of forcing the developer to think about the unhappy path in every layer. Maybe a bit more code, but the quality of diagnostics - priceless. Except what happens in practice is that people just put panics everywhere because most of the time there is no meaningful action one can take at the layer where the implementation happens. Actual examples in servo: https://pastebin.com/0DAFU9vS https://pastebin.com/0DAFU9vS I also invite you to run the following command: $ cd ~/.cargo $ rg panic! | wc -l I get 2987 as a result. Choosing to program like this instead of using exceptions which at least can be recovered by the person who will use your lib, is literally hateful towards users. I've not seen Go code to be meaningfully different either. > IMHO exceptions/panics should be reserved for bugs only (eg assertions), and return values for all the other error handling caused by user input or environment. Sure, this is the community consensus in C++. It's the Python people who use exceptions to get out of for loops :) But the most important rule is that - invalid state must not be representable in the program. There must be no way to get an "invalid" object (unless the object being invalid is part of its possible domain, but this is exceedingly rare when one isn't interfacing with a 1985 C API)

Not if it's part of the state of your app ? E.g. a struct member. It also replaces an automated and enforced action by the compiler (exception being thrown) by a need for a manual check which feels very 1975

Thorrez 5y ago
>Not if it's part of the state of your app ? E.g. a struct member. I'm not sure what you mean. Here's an example with the output from std::optional being unwrapped and put in a struct member: https://godbolt.org/z/Ms4Kar18j https://godbolt.org/z/Ms4Kar18j Also there's opt.value_or() which can use a default value in the case opt is nullopt. >It also replaces an automated and enforced action by the compiler (exception being thrown) by a need for a manual check which feels very 1975 I think remram's goal was to avoid exceptions. So this is a criticism of remram's goal rather than the method to achieve that goal. Also, std::optional can integrate with exception-producing code because opt.value() throws an exception if opt is nullopt.
- jcelerier 5y ago
  > I'm not sure what you mean. Here's an example with the output from std::optional being unwrapped and put in a struct member: https://godbolt.org/z/Ms4Kar18j https://godbolt.org/z/Ms4Kar18j And now you have to do this for every type that have some amount of preconditions. I don't understand in which universe this is sane - more code == more bugs. e.g. here's what one would write with exceptions: https://godbolt.org/z/evMsh6383 https://godbolt.org/z/evMsh6383 (and, to be honest, if one is writing e.g. a command-line tool and not a reactive gui app, most likely https://godbolt.org/z/eW8YM5Gz4 https://godbolt.org/z/eW8YM5Gz4 as your OS will catch the thing anyways and then it's just a `coredumpctl gdb` / "open in debugger" away) ; you get the same guarantee of never having an invalid Foo but at much less mental cost. It also prevents you of having aggregates as all the "parent" owner class will need their own wrapping in optional + private ctor, in case a sub-sub-sub-sub field would fail. e.g. given struct DomainObject { Foo mainFoo; Foo secondaryFoo; int whatever; }; struct GameState { std::vector<DomainObject> objects; }; now you can't just do DomainObject{initForMainFoo, initForSecondaryFoo, 123}; or DomainObject{.mainFoo = "", .secondaryFoo = "", .whatever = 123}; anymore, even less GameState{{DomainObject{...}, DomainObject{...}}; which is how modern C++ is meant to be used
  - pkolaczk 5y ago
    Exception handling may indeed end up with less code, but often it is because the developers forgot to handle most error situations properly. And that's my biggest gripe with exceptions, particularly the unchecked ones, which can just pop up from 100 layers below. I've just seen it too many times when developers just throw exceptions and let them bubble up to a place where there is so little context that the final error message presented to the user is near useless. On the other hand return values (using something like a try/either monad) have the property of forcing the developer to think about the unhappy path in every layer. Maybe a bit more code, but the quality of diagnostics - priceless. IMHO exceptions/panics should be reserved for bugs only (eg assertions), and return values for all the other error handling caused by user input or environment.
    - jcelerier 5y ago
      > I've just seen it too many times when developers just throw exceptions and let them bubble up but it's the whole point ! that's exactly why exceptions are good ! > to a place where there is so little context that the final error message presented to the user is near useless. there are only two valid cases: there's an error that you know you are able to recover from, you did recover, and the users does not see a message and never knows that an error happened, OR the user sees the message "The program has encountered an error. A backup of your data has been saved in c:/foo/. The program will now exit.". Anything else makes software terrible to use. If you have logging and recovery to do, use your logging architecture and core dumps, don't misuse exceptions for that. > On the other hand return values (using something like a try/either monad) have the property of forcing the developer to think about the unhappy path in every layer. Maybe a bit more code, but the quality of diagnostics - priceless. Except what happens in practice is that people just put panics everywhere because most of the time there is no meaningful action one can take at the layer where the implementation happens. Actual examples in servo: https://pastebin.com/0DAFU9vS https://pastebin.com/0DAFU9vS I also invite you to run the following command: $ cd ~/.cargo $ rg panic! | wc -l I get 2987 as a result. Choosing to program like this instead of using exceptions which at least can be recovered by the person who will use your lib, is literally hateful towards users. I've not seen Go code to be meaningfully different either. > IMHO exceptions/panics should be reserved for bugs only (eg assertions), and return values for all the other error handling caused by user input or environment. Sure, this is the community consensus in C++. It's the Python people who use exceptions to get out of for loops :) But the most important rule is that - invalid state must not be representable in the program. There must be no way to get an "invalid" object (unless the object being invalid is part of its possible domain, but this is exceedingly rare when one isn't interfacing with a 1985 C API)