I am clearly opinionated here :)
This works and it reads clearly, but it is devoid of specificity.
You desire to control flow on state, not on error. Error is normally flow control failed.
The code tells nothing about what is expected, only it might fail in certain generic ways.
Try excepts are essentially GOTOs, as flow control they smell?
People will point to the performance hit, but creating the additional stack frame and even unwinding it is usually significant.
The variability of being able to optimize the code in the protected frame varies, so can hit perf noticably or nearly none.
Unless you are using ES7 try blocks are synchronous, so careful with this approach.
My real concern it is backwards and -to me- lazy. If your state is bad in a known detectable way why continue much less spread it to myroutine which may incur other side effects due to caller pollution. Then finding it assuming myroutine has some protection is up the call stack we go.
There are cases where this is the only real choice and there are cases where detection is expensive and or very rare so the trade-off might be compelling. Otherwise, if never approve the PR.
I appreciate that you don’t just accept it and you have an difference of opinion. The world would be boring if no one challenged others. I would love to see you write out the code to show what each of your points refer to.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.