Hi Dave.
Check out this link <https://fsharpforfunandprofit.com/posts/exceptions/>,
but scroll down to the section titled "Should functions throw exceptions or
return error structures?". It's F#, but the comparison is valid to
exception handling vs "functional" error handling using Maybe (Option in
F#) and Result.
In my back-end F# code, I no longer handle exceptions, generally speaking.
I take functions which normally throw exceptions (like SQL queries) and
wrap them in an Result type. Then using things like `map` and `bind` (aka
`andThen`), I can continue my workflow only on success. Then at the edge of
the application, I can deal with the errors differently based on which
specific error occurred. Some could even invoke a program crash if that
makes sense to do. But then I know exactly for which cases I am pushing the
self-destruct button.
All that said, I think you are focusing on the trees and not the forest,
because there's comparatively little need to do this kind of error handling
in Elm, considering it only allows you to write pure functions. The main
times you end up with Result types are parsing and comms. Maybe is more
frequent, but more about presence than error handling.
On Thursday, October 6, 2016 at 9:13:32 PM UTC-5, 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 [email protected].
For more options, visit https://groups.google.com/d/optout.
