> > This means that there is no exception that will bubble up unhandled at > runtime and crash your app. >
Peter, I think you may be misunderstanding the intent of exception bubbling. The idea is not to have the exception bubble up to the top and crash your app. The idea is this. Suppose you have function1 call function2 and function2 call function3 and function3 call function4. And suppose function4 throws an exception. An unrecoverable exception. And suppose that the sole purpose of the exception is to indicate a programming error or a system problem. There is nothing to be "handled". No possible "recovery". The only reasonable way to handle the exception is with a "generic exception handler": 1. log a message 2. print a stack trace 3. update the ui with a generic "system error: please see log" message. For this situation, the established best practice (as far as I know) has always been to allow that exception to bubble up to main and have *one* top-level "generic exception handler" in main. Runtime exceptions are inevitable. An awesome compiler can certainly move certain categories of exceptions from runtime to compile time. Form what I am hearing, Elm is pretty good at that. But exception bubbling is a *feature*. An extremely useful feature. Language level support for exceptions has been a staple of every programming language since C. I do not consider Maybe and Result to be a useful substitute for language level exception support. I could do Maybe and Result in C. Even unix has separate streams for standard versus error. If every function in between main and function4 has to explicitly propagate the exception up the call stack, I see that as adding no value and a bunch of noise to the app. -- 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.
