[elm-discuss] Re: No Runtime Exceptions - Still not computing

[Joel McCracken]

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.

[elm-discuss] Re: No Runtime Exceptions - Still not computing

[Kasey Speakman]

Hi Dave.

Check out this link , 
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 elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] Re: No Runtime Exceptions - Still not computing

[John Coady]

On Friday, 7 October 2016 03:13:32 UTC+1, Dave Ford wrote:
>
> 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).
>

myFunction : Int -> Result String Int
myFunction =
  if x < 1 then 
Err "x must be >= 1"
  else
Some x * x * x
  

errorResult : Result String Int
errorResult = Result.map (myFunction) (myFunction 0)
-> Err "x must be >= 1"

okResult : Result String Int
okResult = Result.map (myFunction) (myFunction 2) 
-> Some 64


"Could have a string error" is kept with the type in the same way that 
"could throw IllegalArgumentException" is.

 

-- 
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.

Re: [elm-discuss] Re: No Runtime Exceptions - Still not computing

[Dave Ford]

On Fri, Oct 7, 2016 at 11:33 AM, Kasey Speakman 
wrote:
>
> Then at the edge of the application, I can deal with the errors
>
Yes. This is what I am trying to figure out. How to deal with that class of
errors at the "edge".

Thanks.

-- 
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.

Re: [elm-discuss] Re: No Runtime Exceptions - Still not computing

[Martin Janiczek]

Dave, how do you think about JavaScript Promises? Where you code for the 
happy path (the chain of Promise.resolve().then().then().then()), any of 
which can throw, and have a .catch() handler that catches whatever the 
thrown value was and does something about it.
The Elm Result type is very similar to this.

Promise.resolve(myValue) ~= Ok myValue
Promise.reject(myErrorData) ~= Err myErrorData
promise.then(fn) ~= myResult.andThen(fn) or myResult.map(fn)
promise.catch(fn) ~= case myResult of Err x -> fn x


Again, a specific example would help. Elm programs are not written the way 
C, C#, Java programs are written. Clojure is closer but because of Java 
interop reasons hasn't adopted much of the Maybe / Result / ... goodness 
and instead has nils like Java has. In Elm the erorrs are explicit (like 
you say, part of the return type). 
Read: http://blog.jenkster.com/2016/06/how-elm-slays-a-ui-antipattern.html 
for how Elm solves the Server Down error you mentioned.

Malformed JSON is also reported not with exceptions but with Result. Either 
you get your value in Ok, or helpful error message in Err. You have to 
handle both cases, it doesn't propagate up, it doesn't throw a runtime 
exception, the user sees what you decided to show him in that scenario. 
Essentially the Elm compiler tells you "This could blow up - you told me 
what to do if the JSON is OK, but what if it is not?"

On Friday, October 7, 2016 at 10:05:50 PM UTC+2, Dave Ford wrote:
>
>
>
> On Fri, Oct 7, 2016 at 11:33 AM, Kasey Speakman  > wrote: 
>>
>> Then at the edge of the application, I can deal with the errors
>>
> Yes. This is what I am trying to figure out. How to deal with that class 
> of errors at the "edge". 
>  
> Thanks.
>
>

-- 
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.

Re: [elm-discuss] Re: No Runtime Exceptions - Still not computing

[Zachary Kessin]

Putting on my  Erlang Developer hat (Moto: Let it Crash) I look at it this
way there are two kinds .of errors, normal errors an exceptional errors.
Lets say you want to go to the store to buy a dozen eggs. There are a few
possible outcomes here

1) You get the eggs
2) You can't buy the eggs (Store is out of stock/ no money etc)
3) You can't get to the store because of some kind of Force Major. (IE The
store burned down, the police have blocked the street due to an abandoned
bag etc)

The elm type system with a Maybe / Result will handle cases #1 and #2. As
for case 3, that is a little harder but can still be handled.

Or to take your examples


   - Invalid function args
   - Malformed JSON
   - Server down

The first one will be handled by the type system. If you try to pass an
invalid argument to a function the code will not compile. Obviously there
are ways to take run time data and test for validity. You can imagine a
function like "parseRomanNumeral : String -> Maybe Int" which takes a
string and attempts to treat it as a roman numeral. But the Maybe is there
for the case where its not.

As for the Malformed JSON then you have enforced error handling code.

In the case of a server down. (As Joe Armstrong said "The best type system
will not prevent your server from being struck by lightning" ). Then you
get a timeout error which you can handle in some useful way




ᐧ

On Sat, Oct 8, 2016 at 5:03 PM, Martin Janiczek  wrote:

> Dave, how do you think about JavaScript Promises? Where you code for the
> happy path (the chain of Promise.resolve().then().then().then()), any of
> which can throw, and have a .catch() handler that catches whatever the
> thrown value was and does something about it.
> The Elm Result type is very similar to this.
>
> Promise.resolve(myValue) ~= Ok myValue
> Promise.reject(myErrorData) ~= Err myErrorData
> promise.then(fn) ~= myResult.andThen(fn) or myResult.map(fn)
> promise.catch(fn) ~= case myResult of Err x -> fn x
>
>
> Again, a specific example would help. Elm programs are not written the way
> C, C#, Java programs are written. Clojure is closer but because of Java
> interop reasons hasn't adopted much of the Maybe / Result / ... goodness
> and instead has nils like Java has. In Elm the erorrs are explicit (like
> you say, part of the return type). Read: http://blog.jenkster.
> com/2016/06/how-elm-slays-a-ui-antipattern.html for how Elm solves the
> Server Down error you mentioned.
>
> Malformed JSON is also reported not with exceptions but with Result.
> Either you get your value in Ok, or helpful error message in Err. You have
> to handle both cases, it doesn't propagate up, it doesn't throw a runtime
> exception, the user sees what you decided to show him in that scenario.
> Essentially the Elm compiler tells you "This could blow up - you told me
> what to do if the JSON is OK, but what if it is not?"
>
> On Friday, October 7, 2016 at 10:05:50 PM UTC+2, Dave Ford wrote:
>>
>>
>>
>> On Fri, Oct 7, 2016 at 11:33 AM, Kasey Speakman 
>> wrote:
>>>
>>> Then at the edge of the application, I can deal with the errors
>>>
>> Yes. This is what I am trying to figure out. How to deal with that class
>> of errors at the "edge".
>>
>> Thanks.
>>
>> --
> 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.
>



-- 
Zach Kessin
SquareTarget 
Twitter: @zkessin 
Skype: zachkessin

-- 
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.

Re: [elm-discuss] Re: No Runtime Exceptions - Still not computing

[Kasey Speakman]

Excellent. Then check out this:

http://fsharpforfunandprofit.com/rop/

On Friday, October 7, 2016 at 3:05:50 PM UTC-5, Dave Ford wrote:
>
>
>
> On Fri, Oct 7, 2016 at 11:33 AM, Kasey Speakman  > wrote: 
>>
>> Then at the edge of the application, I can deal with the errors
>>
> Yes. This is what I am trying to figure out. How to deal with that class 
> of errors at the "edge". 
>  
> Thanks.
>
>

-- 
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.