> > Elm actually can have runtime exceptions. > I think the best way to address this is to have a debugging guide for runtime exceptions. It typically boils down to:
- Don't recurse infinitely - Don't call *Debug.crash* unless a case is unreachable but the compiler doesn't know that - Beware a few bugs, such as #873 <https://github.com/elm-lang/elm-compiler/issues/873> and the current Array implementation. That said, having a better traceback for runtime errors would be nice. Currently I think the stack trace just goes to some top-level exception handling code and you can't tell where it came from. > I personally find it useful to step through code that contains logic > errors, which is to say branches of code that are executing that I didn't > expect to be executing, or a function executing with an unexpected value. > Tracing back up the call stack and stepping through code helps me diagnose > where I made a logic error. Conditional breakpoints are extremely helpful > with this kind of troubleshooting. > Secondly, in my experience these sorts of bugs are rare. Maybe you're writing too-complex branching logic and need to break out some functions with clear contracts and testing paths? In the meantime, try *Debug.log*. I'll drop a *debugger* statement in (non-elm) JS pretty frequently to poke around, see what things are, see what's in scope, etc, but that's largely because I don't know these things from the type system. Why don't we get a hard-to-debug, logically incorrect, compiling piece of code and see what the best tools would be to address it? -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
