Blog

A lot of JavaScript developers speak in exceptions. However, JavaScript does not have any defined practices on “good exception handling”. What does good mean? All using try/catch, .catch for Promises, and window.onerror in the browser or process.on for Node.js? Just http/file reading/writing calls? 3rd party/vendor systems? Code with known technical debt? None “because fast, dynamic language”?

In my view, good exception handling is no exceptions. This means both writing code to not throw Exceptions, nor cause them, and ensuring all exceptions are handled.

Skip Intro, Show me the Vids

I’ve been watching a lot of Dave Farley’s YouTube channel lately, and it’s spawned a lot of gears in my head. One in particular is “translating OOP people”. Specifically, our software industry will say things, and many times the speaker will assume they’re talking to an Object Oriented Programming audience. They’re drop words like “abstraction”, “coupling”, or “Bounded Context” as if that’s the way things are done, supposed to be, and everyone just needs context.

This guide will help you learn and migrate to Elm with assumption you already know the basics of React. The Elm guide is great and will give you a thorough understanding of everything you need to know, in a good order.

This guide is different. Instead, we’re going to start with the fundamentals of JavaScript & React, and how you’d do the equivalent, if any, in Elm. If you already know React, we’ll use those firm groundings so you can feel more comfortable understanding “what Elm means” when they say something using language and concepts familiar to React developers.

Introduction

You can’t use ReScript to call ReScript incorrectly because the compiler will help you make it correct. You can’t use ReScript to call JavaScript wrong because the compiler will help you make it correct.

However, when JavaScript calls your ReScript library, it can do it incorrectly because JavaScript has no compiler; you just run it. This can ruin all the benefits of ReScript: null pointers, runtime errors, and super strange internal ReScript standard library errors that make no sense with stack traces that are not helpful.

Instead, the better thing to do is check the types at runtime, and if wrong, provide helpful runtime errors with what the JavaScript developer needs to do to fix the error. If you’re a ReScript developer providing libraries for JavaScript developers, this article is for you.