4 ms·

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 departur

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
- kortilla 4y ago
  You’re missing the point of exceptions. When you throw an exception, you’re not supposed to care where it lands. That’s the caller’s responsibility. “Who will catch this” is supposed to be opaque. It’s like wondering who will call this function. If you want to goto some specific point in the code, just call it.

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
kortilla 4y ago
You’re missing the point of exceptions. When you throw an exception, you’re not supposed to care where it lands. That’s the caller’s responsibility. “Who will catch this” is supposed to be opaque. It’s like wondering who will call this function. If you want to goto some specific point in the code, just call it.