On Monday, August 21, 2017 at 9:41:55 PM UTC+1, Dave Doty wrote: > > But it does make me long for runtime exceptions for those errors where you > know that not only the current function, but also any function that may > have called it, really isn't going to be able to do any error-handling or > recovery more sophisticated than "print error message and stack trace to > screen". >
Some thoughts: Debug.crash is Elms equivalent of "throw RuntimeException". There is no mechanism to 'catch' these runtime exceptions. Maybe.Nothing and Result.Error are Elms equivalent of checked exceptions. Dealing with Nothing or Error is equivalent to "catch (SomeExcetion e)". Some compensating action should be taken to recover from the exception (such as using a default value). Within a 'unit of work' you should not catch and error recover from a runtime exception. They should really be left as a mechanism that is dealt with at a platform level. In Java if I throw a runtime it should either fall out of main() and cause the VM to exit with an error code and a stack trace, or fall through to application server or framework code (Spring Boot, Dropwizard) that my business logic is running within. The effect should be to terminate the current unit of work completely without committing any of its state, since the application is now in an unknown state and should not continue. In the application server or framework code cases, the runtime is caught and recovered from by abandoning the unit of work but also returning the thread that was running it to the pool so that it can pick up fresh work in a clean state. Thinking of the browser as the framework, it is the only sensible place to catch your Debug.crash and the effect will be to terminate the Elm program. So elm does not need a mechanism to catch runtime exceptions. In order of desirability, I would recommend: 1. Trying to use Elms type system to design data models that do not permit invalid states. 2. Enforcing 'invariants' with checks in code to rule out invalid states. If failures of these checks can be recovered from automatically then there will be no need to use Maybe (in the non-empty list example, you might decide max of an empty list is ok to be zero). In many cases Maybes will creep in. I notice Evan is always banging on about invariants; good man. 3. Don't feel so bad about using Debug.crash to mark impossible states in your code. Sometimes using Debug.crash (or throw IllegalStateException) feels like you are being lazy, or too stupid to have found a better solution. Don't do it out of laziness, but do allow yourself to be too stupid. When you are too stupid put in the assertion and use your tests to check that it can never happen. Over time you get better at 1 & 2 but there is no magic solution to always producing perfect code with all invalid states ruled out. -- 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 elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
