4 ms·

Food for thought: what are the expected consequences of the exception? If the error will stop the program flow and show a warning dialog to the user, it's usel

• em3rgent0rdr 4y ago
  "Exceptions should be... the exception." :)
  • arcticbull 4y ago
    The problem is exceptions have entirely opaque flow control. They're the opposite of a goto statement: a comes-from statement if you will. Flow control could originate literally anywhere down the stack and that makes reasoning about what's happening very difficult. Depending on the language it can also have a super broad and ever-changing surface area.
    • groestl 4y ago
      There's nothing opaque about having an implicit potential return after every line as well as an implicit additional error result value. Think Go, but without the ceremony.
    • kortilla 4y ago
      This is not correct, a “comes-from” statement would still be the same behavior as a goto except it’s defined at the label and there is no “goto” at the departure line. Exceptions are just “goto whatever catch is in the call stack”. It’s still completely obvious when you see a throw statement that it can throw, and static analysis can tell you exactly what can be thrown by each function.
      • ilyt 4y ago
        And it is still opaque where it goes to the programmer when they see it in code. The fact you can use tools to find where it might land (yeah, no shit, you can do same for goto...) is just a mitigation to the problem.
        • rightbyte 4y ago
          It unwinds the call stack until a catch. It is the same "problem" as not knowing where a return will return to.
          • arcticbull 4y ago
            Return only ever moves up the stack one level. That makes it really easy to reason about. This can move up the stack an unlimited amount, and the handler has to be prepared to properly deal with the current state, no matter where it comes from.
            • kortilla 4y ago
              This is no different than returning an error in go far down. You don’t know how far up it will be passed or handled.
              • arcticbull 4y ago
                You do. Errors have to be handled or passed up explicitly at each level. Errors are one level at a time, not 'n'.
          • ilyt 4y ago
            No, it is not the same problem. You need to trace every function, and every function calling those functions, and every function calling those functions, all the way to catch. You can't "just" search for function name, you have to rely on code analysis tools. Making code more opaque coz you can get thru the mess of it via tooling is terrible direction
        • 4y ago
    • snordgren 4y ago
      Unchecked exceptions need extra care. I've seen process level exceptions being logged when the underlying cause was a failure to parse an integer. The exception was being caught in an exception handler half a dozen scopes away.
• grishka 4y ago
  Exception is a way to return from a function abnormally. So yes, they are for exceptional conditions. IMO it's perfectly fine to use them for input validation. The Java standard library itself does it all the time.
  • knorker 4y ago
    Java is the... uhm... exception here. That's not how idiomatic C++ is. Nor Rust. Nor Go. One of Java's (incl standard library) main design flaws is overuse of exceptions. It should not be emulated. It's too late to fix Java, but that doesn't make it a good idea.
    • twic 4y ago
      Rust uses Result. Checked exceptions are Java's analogue of Result.
      • knorker 4y ago
        I disagree. Exceptions are a fundamentally different control flow. Exceptions are exceptions. Return values are not. I would not call std::optional in C++ any form of checked exception, and the difference isn't that std::optional doesn't carry value-missing metadata.
    • grishka 4y ago
      So what do you do in C++ if the input to your function is not what you expect?
      • gilbetron 4y ago
        Return an error or fatally exit the program, depending.
        • grishka 4y ago
          If you return an error, it needs to be checked for in every place where this function is called. Yes, I know C libraries and OS APIs do this often, but that's C, it's the only thing it can do. This just invites human error. Besides, it's often desirable to handle multiple different error conditions (arising from different steps as you process the input data) in one place, which is complicated with this approach. Java-like exception handling makes it easy to handle all errors in a single place and be sure none go unnoticed. This is especially useful when you're accepting external input (a file, a network packet/stream, an HTTP request, etc). If you exit the program on error, this does work in some cases like command-line utilities, but your users would not be happy if your GUI app crashes when you open a malformed file.