18 ms·

Let's say you have server or daemon and you call some library function - if it was written with such careless approach, whole server will fail just because user

Let's say you have server or daemon and you call some library function - if it was written with such careless approach, whole server will fail just because user record had invalid email address, or because some entered data was not in expected format. Let's say you have CLI tool - instead of message "XX is a directory - file expected" your tool will just fail silently. There are much more examples. Graceful shutdown is what we have to do, even laziest of us.

jashmatthews 7y ago
Validation would be an expected Error and handled by returning an Err() rather than using unwrap() or expect(). .expect(format!("{} is a directory - file expected")) gives exactly the behaviour you've described for a CLI tool. Graceful shutdown means releasing locks, deleting PID files etc when encountering an unrecoverable error. Not just any error.
- EugeneOZ 7y ago
  > Validation would be an expected Error and handled by returning an Err() rather than using unwrap() or expect(). When language allows you to make all errors "expected", it's really stupid to don't use it. Only reason is laziness.
  - jashmatthews 7y ago
    I don't understand what you're trying to say here. Laziness has nothing to do with it. Returning a Result vs using .expect("this should never be missing or an error") is about whether your program can continue after this error.
    - EugeneOZ 7y ago
      No, panicking is not a correct way to handle programm execution, it's just "I don't want to care about this possible error case right now", nothing more. I gave you 2 examples and you preferred to ignore them or say "it's ok". Let's agree to disagree, I will never understand people who are too lazy to allow panicking in their code and say "works as intended". Many languages don't have Result types to return so there you can't do much sometimes to prevent data corruption or something worse. But in languages where you can return more than just "false", it's not acceptable.

jashmatthews 7y ago

Validation would be an expected Error and handled by returning an Err() rather than using unwrap() or expect(). .expect(format!("{} is a directory - file expected")) gives exactly the behaviour you've described for a CLI tool. Graceful shutdown means releasing locks, deleting PID files etc when encountering an unrecoverable error. Not just any error.

EugeneOZ 7y ago
> Validation would be an expected Error and handled by returning an Err() rather than using unwrap() or expect(). When language allows you to make all errors "expected", it's really stupid to don't use it. Only reason is laziness.
- jashmatthews 7y ago
  I don't understand what you're trying to say here. Laziness has nothing to do with it. Returning a Result vs using .expect("this should never be missing or an error") is about whether your program can continue after this error.
  - EugeneOZ 7y ago
    No, panicking is not a correct way to handle programm execution, it's just "I don't want to care about this possible error case right now", nothing more. I gave you 2 examples and you preferred to ignore them or say "it's ok". Let's agree to disagree, I will never understand people who are too lazy to allow panicking in their code and say "works as intended". Many languages don't have Result types to return so there you can't do much sometimes to prevent data corruption or something worse. But in languages where you can return more than just "false", it's not acceptable.