What actually happens is "no uncaught runtime exceptions". If an operation can fail, it *MUST* be expressed in the type, and when you call the operation, you *MUST* handle the failure case.
Your program will never crash because of a null pointer or file-not-found or an array out of bounds, but it also will not fail silently unless you go out of your way to make it do so. What will happen is you will handle the error case, and either come up with a sensible default, or tell your program to display some error message, or do something else to properly handle the error. It means that there's no forgetting to check the error codes, like you get in C all the time. And there most certainly will not be an "undefined is not a function" nested deep in some complex operation chain, as you get all the time with JS. Take a look at Array.get: http://package.elm-lang.org/packages/elm-lang/core/latest/Array#get If you have an array of T, instead of returning a T with the possibility of a crash, it returns a Maybe T. The programmer is forced to check if there was an array-out-of-bounds error. The program will not compile otherwise. (That said, in the common case, like iterating through a whole array, there's Array.map, which never fails, because it only looks at array elements that are actually there). On Thu, Oct 6, 2016 at 7:13 PM, Dave Ford <df...@smart-soft.com> wrote: > I have listened to a number of podcasts where Richard Feldman boasts > about never getting a runtime exception. > > I am having a hard time grasping the concept. I think I look at runtime > exceptions a bit differently. I look at them as a *positive*. A > programmers tool. A debugging tool. A way to communicate up the call stack. > A way to separate the error stream from the standard stream. > > For example, a java newbie might do this: > > void myFunction(int x){ > if(x < 1){ > * log("error: x must be >= 1"); * > * return 0* > } > return x * x * x; > } > > A more experienced developer might do this: > > void myFunction(int x){ > if(x < 1){ > *throw new IllegalArgumentException("error: x must be >= 1"); * > } > return x * x * x; > } > > I look at runtime exceptions as a good thing. It's kind of like having two > returns. One return for the normal answer (return). And another for error > conditions (throw). Just like unix has two output streams: one for normal > messages and one for error messages. This allows the caller to handle the > normal return value and the *top-level* caller to handle (i.e. catch) the > errors (usually by logging a stack trace). > > So I don't get it. If I don't have runtime exceptions, what do I do when > someone passes an invalid argument? What do I do if some pre-condition is > not as I expected? Some JSON returned from the server is not in the correct > format? Are we back to just *one* return value for both error conditions > and normal conditions? > > Technically speaking, in java, if I wanted to create an app with no > runtime exceptions it would be real easy. I could just swallow invalid > arguments and let the program fail in a super mysterious way, farther > upstream (the opposite of fail-fast). But I wouldn't boast about that. Or I > could just have a try/catch in my main method that caught every exception > and swallowed it or logged it. > > If Richard said he wrote apps with no *bugs*. That would be impressive. > But an app with no runtime exceptions seems like a silly thing to boast > about. I see 3 kinds of bugs in my java apps: > > 1. *Compile errors.* These are the easiest to deal with. These are > preferred. But I don't see the compiler catching the above mentioned > IllegalArgumentException*. *Or a piece of bad JSON from the server. > > 2. *Runtime Exception. *Like a NullPointerException or an > IllegalArgumentException. I *love* these kind of bugs. Super easy to > find. Super easy to fix. A stack trace tells me exactly where to look. > These kind of exceptions have never been a thorn in my spine. > > 3. *The mystery bug. *Program is just not producing the correct output. > No idea why. No idea where to start looking. No error message. No stack > trace. These are the worst kind of errors. > > In my opinion one of the key differences between an experienced developer > and a beginner developer is that an experienced developer fails-fast with > compile errors (#1) or runtime exceptions (#2). Beginner developers fail > mysteriously with (#3). > > So, based on my understanding, the whole "no runtime exceptions" concept > is just not computing. > > But I am new to Elm. Surely I am misunderstanding something. Please tell > me what I am missing. > > > -- > 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. > -- 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.
