In the docs for
Debug.crash before it), it says:
The Elm compiler recognizes each
Debug.todoso if you run into it, you get an uncatchable runtime exception that includes the module name and line number.
I’d like to understand what the technical meaning of “uncatchable” is in this sentence.
For context, we’ve been progressively upgrading our Elm 0.18 codebase to Elm 0.19. We have yet to enable the
--optimize flag for our Elm 0.19 builds, because in a number of places we are using code like this:
case something of Value1 -> -- … Value2 -> -- … ImpossibleValue -> Debug.todo "This is meant to be impossible."
Of course we do our best to “make impossible states impossible” using the type system, but every once in awhile, despite our best efforts to model our data and state accurately, we do end up having to provide an implementation for a message that we expect we’ll never get. Of course if we turn out to be wrong about this, we want to find out, so we had been using
Debug.crash in Elm 0.18 (which is now
That said, so far we have yet to see any such errors turn up in our monitoring, and I’m wondering if this word “uncatchable” might have something to do with it. Is there something special about the way
For anyone who might be wondering the “right” way to do this, we do have some of our Elm apps well integrated with our error tracking via a
port. We aim to roll this approach out across all our codebases in time.