avoid throwing for flow control

[charlierudolph]

Instead of having a try/catch around this function just have it return an optional error message.

[charlierudolph]

Think its better to hardcode the engines here as well so this doesn't suddenly fail when we no longer support version 17 (probably a little ways off)

[mattwynne]

💯, I missed that.

[davidjgoss]

Oh true, the list right now is 12, 14, 16, 17

[coveralls]

Coverage decreased (-0.002%) to 98.163% when pulling 8c8bd82 on no-exceptions-for-flow-control into 7099a6a on main.

[aurelien-reeves]

Avoiding throwing an error can be a good idea 👍

But rather than returning string | null - which actually I would have expect to be the return type of the validateNodeEngineVersion function- with the string being kinda error message, would it be possible to return something that would look like a result struct which could looks like the following?

{
  status: bool,
  message: string?
}

Or, just, a boolean, and the caller could be responsible for the error message?

[mattwynne]

I did consider using a promise as a kind of Maybe object, so the calling code could do something like

validateNodeEngineVersion(process.version).catch(errorMessage => {
  console.error(error) // eslint-disable-line no-console
  process.exit(1)
})

Still using exceptions for flow control really, but perhaps it reads better?

Another alternative would be to pass the assertion function a callback to run if the engine is invalid, like:

validateNodeEngineVersion(process.version, errorMessage => {
  console.error(error) // eslint-disable-line no-console
  process.exit(1)
})

That way the conditional stays inside the function. That's probably my favourite of them all.

[davidjgoss]

@mattwynne I quite like the callback idea there.

[mattwynne]

lovely!

It's from an older version of the code.

[mattwynne]

I just realised we should have changed these example descriptions too: we're not returning anything anymore.