Mean silent fail in file upload forms

Hi there,

I thought about posting this as an issue for the elm/file package, but I am not sure if it is right there. So I’ll just write this here and hope you have some feedback for me and/or this issue.

We just debugged a silly mistake which was really hard to find, because the on “change” function fails silently when you mess up your Decoder. I made a small example (stolen from the docs):

This works:
https://ellie-app.com/5CZ3rKQrFYYa1

This doesn’t:
https://ellie-app.com/5CZ3XVgjRSfa1

The first tries to decode the files field as a list, the second one as a single file element. In the broken version the Msg is just not triggered. Our somewhat new elm dev was pretty frustrated with this behaviour. What do you think, is this something that could/should be fixed? Could we make elm not just silently swallow the error? Or write it in the docs? The mean thing is, the docs for on say:

When an event occurs, the decoder tries to turn the event object into an Elm value. If successful, the value is routed to your update function.

But no mention of the error case.

Thanks for your input!

If you want to debug the decoder you could make it return a Result String a instead of just a

Here is your failing example with a decorator for the decoder:
https://ellie-app.com/5D65w9GCyQqa1

Thanks, that sounds like an awesome best practice for json decoders. I am probably spoiled because I’ve always controllen the API I was working with when writing elm frontend code, but out there in the wild you should probably always do that.

With that pratice in mind it seems less important for that error to get more vocal, but I still think that it is bad that this particular error is just silent. I would expect a huge warning sign in the docs at least. Is it me, or do others think so too?

Json decoder failures are always present when dealing with http calls. (It will produce a BadBody error) The silent failure is only when dealing with decoding events. That silent failure is actually a feature because it allows one to not generate messages on certain event conditions.

It is a very, very small “feature” since adding a no-op message is trivial. I think compiler-enforced error checking is worth this small inconvenience in the same way it is for http requests.

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.