I think your suspicions are largely right, and your concerns are valid.
However:
Not all exceptional situations are created equal. Some happen more
frequently than others, and many are due to programming errors, where
things just aren't "wired up correctly", and not all cases are handled.
Elm's type system helps with these.
I do not believe you can use the type system to prevent stack a overflow,
for example. At least, you can't do it in a "general way", e.g. static
analysis can catch the stack overflow conditions before they occur.
There are lots of ways though that you may encode the "restraints" of your
system. In your example, I would say that your function should not take an
"Int", instead it should take a "Nat". Then, you have a function "intToNat"
that returns a "Result" -- either it successfully converted the "Int" to a
"Nat", or it failed, with an "Error" (e.g. the int was <1). You use this
function as far out toward the "edge" of your system (ideally, directly in
the update loop function). The update function is the right place to deal
with invalid inputs, as you may choose to tell the user about the problem,
or log an error with something like Bugsnag, etc.
Garbage in, garbage out, of course. But, the tools elm gives you allows you
to have simpler "core" logic. And you may be sure that this core logic is
free of certain classes of errors.
On Thursday, October 6, 2016 at 10:13:32 PM UTC-4, Dave Ford 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.
