3 ms·

I went right into the code and looked for 'if' statements without 'else' statements. There are plenty. I don't see how you can have any exceptions to this rul

I went right into the code and looked for 'if' statements without 'else' statements. There are plenty. I don't see how you can have any exceptions to this rule if you are truly committed to capturing all branches.

throwanem 2y ago
If the 'if' condition matching always results in a thrown exception, a return, or likewise, then you don't really need an 'else' unless you're using a language which supports conditions and resumption (conformant Common Lisp implementations, and not really anything else I know of). The 'else', implicitly, is that the flow of control leaves the scope of the 'if' block at all. (I haven't read far enough into the code to know that this is what they're doing, but the head matter I did read suggests as much. It's a common enough pattern, especially around eg argument validation and other sanity checks a function might perform to ensure it can do meaningful work at all.) (I do wish HN supported an inline monospace markup, the <code> to a four-space indent's <pre>...)
- iainmerrick 2y ago
  Swift's "guard" statement would be pretty handy here.
  - drewcoo 2y ago
    if (foo) { bail out } They're known as guard statements regardless of language. https://en.wikipedia.org/wiki/Guard_(computer_science) https://en.wikipedia.org/wiki/Guard_(computer_science) Swift has a guard keyword, but the construct feels a little awkward given most languages do the above. It makes me do a double take. guard !foo else { bail out }
    - iainmerrick 2y ago
      No, "guard" in Swift is special. Once you're in the "else" block, you MUST return or call a non-returning function (e.g. abort). It's specifically designed to prevent bugs where flow control accidentally resumes from an error handler. It's the same idea as the "every 'if' must have an 'else'" guideline in the code being discussed, except with "guard" the compiler will detect violations. It's a good thing.
- kazinator 2y ago
  "Else" is for when the if condition is false. A resumable exception initiated in the "then" part of an if will not go to "else" when control resumes; it will go to the next statement after the if.
  - throwanem 2y ago
    I did not say exceptions could be resumed (correctly 'restarted'); I said conditions could. Most languages with which I'm familiar do not have the latter. One typically available restart is to ignore the condition and resume execution immediately after, as you describe. Another is to re-evaluate the form in which the condition was signaled. In that case, the conditional may well be itself re-evaluated with a different result, executing a different branch.
    - kazinator 2y ago
      An if-like conditional construct will not, by itself, re-evaluate the condition when an exception occurs, unless it is a special exception-aware construct (a weird macro someone made). The conditional construct would itself have to have an internal restart point around the conditional expression, which intercepts the exception. "Condition" is just a silly name for "exception". It does not mean "restartable exception". It's a terminology that Common Lisp copied from PL/I. At the time Common Lisp was being standardized, it was not a common programming language feature, so the naming didn't matter. In the decades since, the world went to "exception". The word "condition" already has a clear meaning in computing, referring to a logical state ("condition control register", "conditional branch", ...). The "condition variable" synchronization primitive (which has no condition-like state!) is bad enough; we don't need to heap more meanings on those words. Note that processor instruction sets have exceptions, precisely restartable, down to the instruction, without requiring a cooperating restart point. E.g. any code can hit a page fault: the exception handling will fix it up, making a page present at the faulting address, and then restart the instruction that faulted.
mypalmike 2y ago
Someone has obviously simplified the code. Oops.
OJFord 2y ago
Yeah, I immediately scrolled down to see how silly I thought it looked, and.. it's not, there are plenty of ifs without elses. If you're going to have exceptions to that rule where it's 'simple' and not necessary, then congratulations you're using if (and else or not) just like everyone else?

throwanem 2y ago

If the 'if' condition matching always results in a thrown exception, a return, or likewise, then you don't really need an 'else' unless you're using a language which supports conditions and resumption (conformant Common Lisp implementations, and not really anything else I know of). The 'else', implicitly, is that the flow of control leaves the scope of the 'if' block at all. (I haven't read far enough into the code to know that this is what they're doing, but the head matter I did read suggests as much. It's a common enough pattern, especially around eg argument validation and other sanity checks a function might perform to ensure it can do meaningful work at all.) (I do wish HN supported an inline monospace markup, the <code> to a four-space indent's <pre>...)

iainmerrick 2y ago
Swift's "guard" statement would be pretty handy here.
- drewcoo 2y ago
  if (foo) { bail out } They're known as guard statements regardless of language. https://en.wikipedia.org/wiki/Guard_(computer_science) https://en.wikipedia.org/wiki/Guard_(computer_science) Swift has a guard keyword, but the construct feels a little awkward given most languages do the above. It makes me do a double take. guard !foo else { bail out }
  - iainmerrick 2y ago
    No, "guard" in Swift is special. Once you're in the "else" block, you MUST return or call a non-returning function (e.g. abort). It's specifically designed to prevent bugs where flow control accidentally resumes from an error handler. It's the same idea as the "every 'if' must have an 'else'" guideline in the code being discussed, except with "guard" the compiler will detect violations. It's a good thing.
kazinator 2y ago
"Else" is for when the if condition is false. A resumable exception initiated in the "then" part of an if will not go to "else" when control resumes; it will go to the next statement after the if.
- throwanem 2y ago
  I did not say exceptions could be resumed (correctly 'restarted'); I said conditions could. Most languages with which I'm familiar do not have the latter. One typically available restart is to ignore the condition and resume execution immediately after, as you describe. Another is to re-evaluate the form in which the condition was signaled. In that case, the conditional may well be itself re-evaluated with a different result, executing a different branch.
  - kazinator 2y ago
    An if-like conditional construct will not, by itself, re-evaluate the condition when an exception occurs, unless it is a special exception-aware construct (a weird macro someone made). The conditional construct would itself have to have an internal restart point around the conditional expression, which intercepts the exception. "Condition" is just a silly name for "exception". It does not mean "restartable exception". It's a terminology that Common Lisp copied from PL/I. At the time Common Lisp was being standardized, it was not a common programming language feature, so the naming didn't matter. In the decades since, the world went to "exception". The word "condition" already has a clear meaning in computing, referring to a logical state ("condition control register", "conditional branch", ...). The "condition variable" synchronization primitive (which has no condition-like state!) is bad enough; we don't need to heap more meanings on those words. Note that processor instruction sets have exceptions, precisely restartable, down to the instruction, without requiring a cooperating restart point. E.g. any code can hit a page fault: the exception handling will fix it up, making a page present at the faulting address, and then restart the instruction that faulted.

mypalmike 2y ago

Someone has obviously simplified the code. Oops.

OJFord 2y ago

Yeah, I immediately scrolled down to see how silly I thought it looked, and.. it's not, there are plenty of ifs without elses. If you're going to have exceptions to that rule where it's 'simple' and not necessary, then congratulations you're using if (and else or not) just like everyone else?