I haven't asked others on the team, but the only times I can recall seeing any in development, they weren't a surprise - e.g. I was mocking something up with Debug.crash with the goal of "I'll finish implementing this later, but for now I just want it to compile so I can try out the rest of what I've done" and then reaching one of the code paths that called Debug.crash as I was playing around with it.
Of course that's what I expected it to do, and naturally I replace every Debug.crash with a real implementation long before making a pull request!
As the ops guy at NRI responsible for Elm, the main source of errors with Elm is actually during builds. From 0.15-0.17, Elm did not correctly handle the caching of artifacts, leading to occasional compile errors that were not reproducable easily. It was simple enough to fix - just wipe the artifacts. But that also slowed the builds down a lot.
I'm also fairly certain I'm the leading expert on runtime exceptions in Elm - it's possible to make them happen, but most of the time you have to really understand Elm to make them happen. Unless you're using Array or Regex, of course. Both of these can lead to runtime exceptions - e.g Regex.regex "[a". However, you'll not likely run into that in production - unless you are taking using input as regex input.. which probably isn't a good idea unless you're escaping things.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I haven't asked others on the team, but the only times I can recall seeing any in development, they weren't a surprise - e.g. I was mocking something up with Debug.crash with the goal of "I'll finish implementing this later, but for now I just want it to compile so I can try out the rest of what I've done" and then reaching one of the code paths that called Debug.crash as I was playing around with it.
Of course that's what I expected it to do, and naturally I replace every Debug.crash with a real implementation long before making a pull request!
As the ops guy at NRI responsible for Elm, the main source of errors with Elm is actually during builds. From 0.15-0.17, Elm did not correctly handle the caching of artifacts, leading to occasional compile errors that were not reproducable easily. It was simple enough to fix - just wipe the artifacts. But that also slowed the builds down a lot.
I'm also fairly certain I'm the leading expert on runtime exceptions in Elm - it's possible to make them happen, but most of the time you have to really understand Elm to make them happen. Unless you're using Array or Regex, of course. Both of these can lead to runtime exceptions - e.g
Regex.regex "[a". However, you'll not likely run into that in production - unless you are taking using input as regex input.. which probably isn't a good idea unless you're escaping things.