Haters Gonna Hate Labeled Flow

Right up front, let me establish the setting for our Journey.

First, there are two blog articles that I’ve come across,

The Dark Side of Javascript: A Look at 3 Features You Never Want to Use – with obvious emphasis on the “Never”
You Can Label a JavaScript if Statement – eliciting a response along the lines of “you can do that ??!”

Secondly, here’s some code I’ve recently written (and redacted for publishing). Let me call attention to lines 22-25:

import { URL } from 'url'; const DOMAINS = new Set([ 'example.com', 'alternate.net' ]); const SEGMENTS = new Set([ 'query', 'search' ]); export function matchURI(uri) { let id = undefined; let url; try { url = new URL(uri); } catch (err) { return { uri, id, reason: 'error' }; } // match against a valid URL const { hostname, pathname } = url; let reason = 'none'; // 😮 "you can do that ??!" processed: { if (! DOMAINS.has(hostname)) { break processed; } reason = 'hostname'; const pathSegments = pathname.split('/') .filter((segment) => (segment !== '')); if (pathSegments[0] === 'resource') { // "/resource/:id" reason = 'pathname'; id = pathSegments[pathSegments.length - 1]; break processed; } if (pathSegments.some((segment) => SEGMENTS.has(segment))) { // "/operation/query?id=:id" reason = 'param'; // id = url.searchParams.get('id'); break processed; } } return { uri, id, reason }; }

And with it, a small illustrative Test Suite:

import assert from 'assert'; import { matchURI } from './matchURI.mjs'; assert.deepStrictEqual(matchURI('UNPARSEABLE'), { uri: 'UNPARSEABLE', id: undefined, reason: 'error', }); assert.deepStrictEqual(matchURI('https://stealth.mil/resource/SECRET'), { uri: 'https://stealth.mil/resource/SECRET', id: undefined, reason: 'none', }); assert.deepStrictEqual(matchURI('https://example.com'), { uri: 'https://example.com', id: undefined, reason: 'hostname', }); assert.deepStrictEqual(matchURI('http://alternate.net/resource/RESOURCE/'), { uri: 'http://alternate.net/resource/RESOURCE/', id: 'RESOURCE', reason: 'pathname', }); assert.deepStrictEqual(matchURI('https://example.com/process/resource/query?id=QUERY'), { uri: 'https://example.com/process/resource/query?id=QUERY', id: 'QUERY', reason: 'param', });

With that all being established, let me toe the line.

GOTO is bad

We all know this to be true.

GOTO cannot be trusted. This is because GOTO has no moral compass whatsoever. GOTO will stand there in a black stove-pipe hat & cloak, glaring at you, curling its mustached menacingly. Then, with a ghoulish cackle, GOTO will tie your innocent, helpless code to the railroad tracks.

GOTO is the bane of our existence. There can be no doubt of this. The GOTO construct – and by association, labels in general – is reprehensible. Its use should be considered a Faustian bargain from which there can be no possible hope of benefit or redemption.

And hooray – I get my Merit Badge! And I take it home, and I proudly sew this new Badge onto my sash, just to the left of “Indent with Spaces”, and below “eval is Evil”.

But, deep inside of me there is a twinge of guilt. For I do not believe this dictum to be true in all cases. I would even go so far as to say that, sometimes, a label is the right tool for the job.

You Can’t Be Serious

Oh yeah, I went there.

Of course, GOTO was pretty essential back in my BASIC days, a time commonly known as “the 1980s”.

I can’t tell you how delighted I would have been to make a Git GIST of some of my old BASIC code. However, I couldn’t find any in my archive.

I imagine it’s all sitting on dessicated cassette tapes, packed away somewhere (along with my CoCo) by my loving mother.

But let’s not get all weepy & sentimental for the good old days. We’re here to talk about GOTO’s enabler, the label. And although the label is entirely complicit in the despicable actions of GOTO, that does not mean that it cannot be reformed with the help of a little T.L.C.

I am not going to provide an exhaustive language survey here. Rather, the two practical examples that come to mind are;

JavaScript has labeled statement support,
Ruby implements Kernel#catch & #throw

A contrived (and unconvincing) example of the Ruby syntax is;

def catchAndThrow(flow) i = 0 if (flow == :return) then return i end catch do |label| # TODO: something useful i += 1 throw label if (flow == :throw) # TODO: moar good stuffs i += 1 end return i end require 'minitest/autorun' describe 'catchAndThrow' do it 'executes a return flow' do _( catchAndThrow(:return) ).must_equal 0 end it 'executes a catch-and-throw flow' do _( catchAndThrow(:throw) ).must_equal 1 end it 'executes any other flow' do _( catchAndThrow(:other) ).must_equal 2 end end

My quick search for a prefab Ruby example led me to this Reddit post, in which the Commenters observe;

[throw/catch is] … basically a GOTO with an optional payload.

The academic answer: raise/rescue is meant for handling exceptional conditions, NOT for control flow. If you want control flow to be able to jump locations (multiple loops, method calls, etc–those not handled by regular conditionals), then you should use throw/catch.

Now of course, not every shit-upon language feature has situational value. I’m wary of the “optional payload” part of Ruby’s syntax (thus I am not demonstrating it).

As far as JavaScript goes … you won’t catch me using a with statement – nor linking to its MDN documentation – and I avoid iterating on Strings as if they were Arrays. Sure, I could … but I won’t.

However, I would propose that, discretionally,

a labeled block is an effective tool for flow control

Heresy!

Hey, hey. Easy. You’ve read this far … now, hear me out.

Let me break down the essence of why & how I have used this nefarious and much maligned labeled statement syntax in my JavaScript parsing code example.

The Code Has Three Phases

decode the URL, which can throw an Error
progressively determine how to derive { id } from the URL
return a consistent payload

Each phase is rather compact. At current length, I feel it reads nicely.

I Was Careful in My Choice of Naming

Let us take another look at lines 22-25;

processed: {
  if (! DOMAINS.has(hostname)) {
    break processed;
  }
  // ...
}

The purpose of the label is for control flow. I chose the name “processed” so that the break processed statement would be expressive to future maintaners. The PR feedback comment it received was:

this is really cool, but I am instinctively fearful of it

Look, I totally get it. Labels and GOTO have maintaned a lengthy and contentious co-dependent relationship. And we’ve all been burned before. It is completely reasonable to ask; “Is Label really ready to move on?”

Yes, Label is ready. Given the right opportunity, Label can shine. But we’ve all experienced trauma, so please take it slow … and be gentle.

Well, I’m Not So Sure …

I can understand that. What alternatives might you propose?

Why don’t you refactor it into smaller Functions?

That is a tried-and-true pragmatic approach.

However I would contend that, of the three phases, the decoding & return-value parts are drop-dead simple. Only the progressive logic is of real “value”, and it could be factored out – much like I did for some top-level consts – but you’ll just end up spreading the end-to-end logic around into two different places.

If the decoding phase were to get more complicated, that might be an incentive to refactor. Whereas the return-value phase is built to match the complexity of what the progressive logic can derive, so they’re already coupled.

I would say that “now is not the time”.

Why don’t you use a try { } finally { } statement?

I agree, that is a viable alternative.

But then you end up using a Exception-handling construct to implement the desired control flow, which I would suggest is a worse shoe-horning of the language. Whereas with the labeled statement,

there’s no contrived Exception-but-not-really implementation; in the end, we want something equally as expressive as the “processed” label
there’s no extra catch(err) { } or finally { } syntactic sugar involved; it’s just a label in front of a block
given the two points above, a Reviewer is likely to have opinions on your alternate solution, too
and, to drive home the point – the labeled statement approach will result in fewer lines of code

Why don’t you replace it all with early returns?

Because that’ll be (a) more lines of code or (b) more complicated code in the same “number of lines”. And, without TypeScript (or a similar formalization) to guide you, the structs of those invididual returns must all be kept in sync.

The decoding step does have its own return, and that makes for a grand total of two. I believe it reads best that way, for purposes of maintainability.

It’s like a switch { case } without breaks !

No. It really isn’t.

For the love of god, refactor this !!!1!

Wow.

Okay. I think I may have overstepped some boundaries here, and for that, I’m sorry. Maybe it would be better to discuss this again at some later time?

Yeah, probably. I could really use some coffee.

Sounds like a good plan .

While you do that, I’ll sum up.

In Summary

The intent of this post was to demonstrate how a label can provide effective and expressive control flow in modern JavaScript code (for example). It also attempts, in some small way, to diminish the stigma associated with labels as a whole.

Time and time again, GOTO has shown itself to be a narcissistic blowhard that ruins everything it touches. Is it any surprise that labels have gotten a bad rap by association?

Perhaps we shouldn’t judge a language feature, even by the admittedly awful company that it keeps.

A Parting Thought

Here’s a neat little tick for dealing with instanbul / nyc code coverage:

/* istanbul ignore next */
_uncovered: {

  // ...

}

NOTE: If your screen reader is reading this, please contact me at admin@cantremember.com ... because it shouldn't. FIXME: build this dynamically based upon the maximum content in any sub-Element of this Element. I will call this my "Safari Reader Counterweight". In some of my Posts, I have huge code excerpts, etc. Safari Reader, at least in iOS, will identify the 'main Element', the one it features, based upon its content length. Sometimes those code excerpts get identified as the 'main Element', and the Post is borked in Safari Reader mode. This is a counter-weight; it gives the <main> Element additional content so that it gets featured, algorithmically. Yes, it increases the payload of every page (@see FIXME above). But not by that much. Then again, this is a guess as to how much content any given Element could contain. If it's not enough, BOOM, Safari Reader looks like crap. So, here's a great article on how to enable Safari Reader on your site. It's mostly guesswork, but those guesses helped me debug this obtuse goddamn problem. Oh, and look, you can enter and exit Reader programmatically. JavaScript can fix anything. I promise I will never cut-and-paste lines of text simply to add Element payload. I promise I will never cut-and-paste lines of text simply to add Element payload. I promise I will never cut-and-paste lines of text simply to add Element payload. I promise I will never cut-and-paste lines of text simply to add Element payload. I promise I will never cut-and-paste lines of text simply to add Element payload. I promise I will never cut-and-paste lines of text simply to add Element payload. I promise I will never cut-and-paste lines of text simply to add Element payload. I promise I will never cut-and-paste lines of text simply to add Element payload. I promise I will never cut-and-paste lines of text simply to add Element payload. I promise I will never cut-and-paste lines of text simply to add Element payload. I promise I will never cut-and-paste lines of text simply to add Element payload. I promise I will never cut-and-paste lines of text simply to add Element payload. I promise I will never cut-and-paste lines of text simply to add Element payload. I promise I will never cut-and-paste lines of text simply to add Element payload. I promise I will never cut-and-paste lines of text simply to add Element payload. I promise I will never cut-and-paste lines of text simply to add Element payload. I promise I will never cut-and-paste lines of text simply to add Element payload. I promise I will never cut-and-paste lines of text simply to add Element payload. I promise I will never cut-and-paste lines of text simply to add Element payload. I promise I will never cut-and-paste lines of text simply to add Element payload. I promise I will never cut-and-paste lines of text simply to add Element payload. I promise I will never cut-and-paste lines of text simply to add Element payload. I promise I will never cut-and-paste lines of text simply to add Element payload. I promise I will never cut-and-paste lines of text simply to add Element payload.