> > Runtime exceptions are inevitable
The successful applications written in Elm proves that they are not. You can keep saying it, but it doesn't make it true. This is a path that Rust is following as well, so it's not like we're the only people in the tech community with this attitude. I could do Maybe and Result in C. Yes, but without higher order functions, you can't do Maybe.andThen and Result.andThen, or Maybe.withDefault, which is what makes them more useful than the C structures. And, you'd have no guarantee that a null pointer along the way wasn't going to bring down your whole program. Elm doesn't allow safety, it enforces safety. On Fri, Oct 7, 2016 at 10:11 AM, Joey Eremondi <[email protected]> wrote: > If you want Exception Bubbling like that, use Maybe.andThen or > Result.andThen. These are exactly what they are for. > > You can bubble your exceptions as high as you like, but (1) that bubbling > is always expressed in the type signature, and (2) there's always something > that will catch it eventually, it can't bubble past the top and crash the > program. > > "No Runtime Crashes" might be a better slogan. We have runtime knowledge > of failure, but we have to do something about it. It will never bring the > whole program down. > > On Fri, Oct 7, 2016 at 10:08 AM, Dave Ford <[email protected]> wrote: > >> 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. >> > > -- 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.
