3 ms·
Sort of agree, but I don't think if (err) { handleError(err) return } and if (err) return handleError(err) are equally good. The sec
by thesimon 9y ago
Sort of agree, but I don't think
if (err) {
handleError(err)
return
}
and
if (err) return handleError(err)
are equally good. The second one doesn't really make it clear wether handleError returns a value and that value is intended to be returned.
- Forge36 9y agoI had to double check the function call occurred. It's not intuitive and removes braces in favor of possible side effects.
- arghwhat 9y agoI don't think the latter is legal in most (non-JS) languages if the return value of the outer function is void. Even if it is, I definitely agree that it should only be done if you want to communicate that handleError's return value is meaningful and should bubble up.
- timoxley 9y agoIf the return value is important: if (err) return void handleError(err) And in non-promise-based async JS, the return value is almost always lost/useless anyway so `return x` has no effect, might as well repurpose `return` for short-circuiting.
- jmull 9y agoI don't think throwing void at people is generally going to make anything clearer.
- timoxley 9y agowhy
- jmull 9y agoIt’s an obscure operator. Many people are unaware of it and many of those that are have a vague notion of exactly what it does. So people reading this code may have to stop and puzzle out this little pattern. Here you can replace “ void “ with a new line and have code anyone with basic familiarity with a c-like language can read and understand intuitively.
- jimmaswell 9y agoI've never seen syntax like 'if (err) return void handleError(err)' before. If I saw that in JS I'd have to look up what it meant.