5 ms·

Exceptions are like returns, they go back up the call stack. You cant statically determine where a return will end up either, since it depends on where the func

by goto11 4y ago

Exceptions are like returns, they go back up the call stack. You cant statically determine where a return will end up either, since it depends on where the function was called. > unlike a Return, the destination is not irrelevant, the program is disrupted, you really need to know where that Throw is going to end up. I don't follow your reasoning here. A function should not know where it returns to and a throw should not know where the exceptions will be caught. That is the point of those constructs. If you know exactly at the point of throwing how you want the exception to be handled, then you wouldn't need to throw an exception in the first place.

Banana699 4y ago
Yes exactly, exceptions are much much nastier returns. Returns only go up exactly 1 frame, and the call/return pairs are balanced no matter what. Exceptions can unwind the entire stack, and the throw/catch pairs aren't balanced automatically. Returns of a single function own their call sites, nobody jumps to their call site except them, but a single catch accept every single throw from arbitrarily deep into the stack. Exceptions are an entire call/return system hidden beneath the vanilla call/return system, with less thought in the design and more foot guns. >I don't follow your reasoning here Okay forget it, it was a somewhat subjective point, my main point is as above, exceptions are extremely spicy returns, they interact dangerously with the regular call/return system and scoping. That's essentially all of what objections to exceptions boil down to, and it's a legitimate reason to hate and avoid them.
- wizofaus 4y ago
  "it's a legitimate reason to understand them properly and use them appropriately" FIFY.
- ncmncm 4y ago
  Exceptions interact exactly deterministically with the call/return system. There is no scope for surprises. In particular, destructors run, absolutely reliably. Rely on them. Using modern C++, you rarely need to code your own destructor; usually the language provides one that is guaranteed to be correct.
- goto11 4y ago
  > the call/return pairs are balanced no matter what. I don't get that. A function can have multiple returns and a return can return to multiple different places depending on where the function was called from. I don't see how they are "paired" or why that would even be a desirable property?
  - ncmncm 4y ago
    Ultimately all arguments against exceptions, as against any modern feature, come down to "don't make me think about how I code". The actual objections expressed are not meant to be examined closely. It is funny that people using Rust would code almost identically if the language had exceptions. Its lack might end up what keeps Rust performance from catching up to and passing C++. The compiler might come to quietly use exception machinery for most call chains, as an optimization. That seems hard, but a 15% performance boost is worth a lot of work.
    - Banana699 4y ago
      That's a very cliche and unnaunced point of view. If you like thinking about your code, you have assembly, I think x86 is a very nice flavor for you, will all its 40+ years galore of special cases. There are Turing Machines, for really testosterone-heavy programmers, there you don't even have registers, registers are for weaklings, am I right ? I think you will like them very much, just an FSM and an infinite tape, the sky is your limit, so much thinking. If you want even more kickass bragging rights, you can program in a Lambda Calculus, where every single thing you try to do with the language will force you to think about it, more thinking ! yaaay ?. Generally speaking, yes, the entirety of good design (in general, in all walks of life) and modern PL research comes down to "don't make me think about how I code", because good programmers don't think about the code, they think about the problem the code is trying to solve. As per Alfred Whitehead (a mathematician, so very much a fan of thinking) : "Civilization advances by extending the number of important operations which we can perform without thinking about them.", so is programming language research. It advances by allowing you to forget as much as possible that you're even programming a computer, a good language fades into the background, ideally you're not even programming a good language, you're simply stating the problem to be solved. This is hampered by leaky and unreliable abstractions like Exceptions. They are a step backward in Error Handling, no static gaurantees, no static type checking, aweful synchronization between use sites.

by goto11 4y ago

Banana699 4y ago

Yes exactly, exceptions are much much nastier returns. Returns only go up exactly 1 frame, and the call/return pairs are balanced no matter what. Exceptions can unwind the entire stack, and the throw/catch pairs aren't balanced automatically. Returns of a single function own their call sites, nobody jumps to their call site except them, but a single catch accept every single throw from arbitrarily deep into the stack. Exceptions are an entire call/return system hidden beneath the vanilla call/return system, with less thought in the design and more foot guns. >I don't follow your reasoning here Okay forget it, it was a somewhat subjective point, my main point is as above, exceptions are extremely spicy returns, they interact dangerously with the regular call/return system and scoping. That's essentially all of what objections to exceptions boil down to, and it's a legitimate reason to hate and avoid them.

wizofaus 4y ago
"it's a legitimate reason to understand them properly and use them appropriately" FIFY.
ncmncm 4y ago
Exceptions interact exactly deterministically with the call/return system. There is no scope for surprises. In particular, destructors run, absolutely reliably. Rely on them. Using modern C++, you rarely need to code your own destructor; usually the language provides one that is guaranteed to be correct.
goto11 4y ago
> the call/return pairs are balanced no matter what. I don't get that. A function can have multiple returns and a return can return to multiple different places depending on where the function was called from. I don't see how they are "paired" or why that would even be a desirable property?
- ncmncm 4y ago
  Ultimately all arguments against exceptions, as against any modern feature, come down to "don't make me think about how I code". The actual objections expressed are not meant to be examined closely. It is funny that people using Rust would code almost identically if the language had exceptions. Its lack might end up what keeps Rust performance from catching up to and passing C++. The compiler might come to quietly use exception machinery for most call chains, as an optimization. That seems hard, but a 15% performance boost is worth a lot of work.
  - Banana699 4y ago
    That's a very cliche and unnaunced point of view. If you like thinking about your code, you have assembly, I think x86 is a very nice flavor for you, will all its 40+ years galore of special cases. There are Turing Machines, for really testosterone-heavy programmers, there you don't even have registers, registers are for weaklings, am I right ? I think you will like them very much, just an FSM and an infinite tape, the sky is your limit, so much thinking. If you want even more kickass bragging rights, you can program in a Lambda Calculus, where every single thing you try to do with the language will force you to think about it, more thinking ! yaaay ?. Generally speaking, yes, the entirety of good design (in general, in all walks of life) and modern PL research comes down to "don't make me think about how I code", because good programmers don't think about the code, they think about the problem the code is trying to solve. As per Alfred Whitehead (a mathematician, so very much a fan of thinking) : "Civilization advances by extending the number of important operations which we can perform without thinking about them.", so is programming language research. It advances by allowing you to forget as much as possible that you're even programming a computer, a good language fades into the background, ideally you're not even programming a good language, you're simply stating the problem to be solved. This is hampered by leaky and unreliable abstractions like Exceptions. They are a step backward in Error Handling, no static gaurantees, no static type checking, aweful synchronization between use sites.