Recommended way to handle errors

#1

I have a suspicion Js.Json must be semi-deprecated (bs-json is probably the way to go), but I tried to decode JSON the way it’s done in an example there and now I have questions regarding errors in general.

  1. Should we use failwith at all? Seems like some Caml pervasive, and I’ve got no idea how to catch it, so I’ve ended up using Js.Exn.raiseTypeError anyway.

  2. Isn’t Belt.Result meant for error handling? Of course it would mean flatMaps everywhere so maybe that’s not the recommended style, but as a user, I’d like to know the recommended style.

#2

I recommend looking at bs-decode for decoding JSON. It provides a type-safe API for handling errors without throwing exceptions.

#3

Interesting, thanks!

My question was rather about the recommended way to handle errors in general, but the existence of tools like this confirms my doubts about exceptions.

Then again, if ReasonReact adopts React Suspense, we’re gonna see a lot of exceptions anyway :slight_smile:.

#4

This article has a good explanation of error handling in OCaml/ReasonML.

#5

Hey, that’s a great article, thanks!

I still wonder what’s if there’s a recommended approach. Somehow I don’t see Let_syntax in Belt.Result :slight_smile:.

#6

Also there’s a relevant Reason town

#7

Let_syntax is in core. you probably need something similiar for let_anything

#8

Yeah, you’re right.

#9

You can monadically compose the errors without ppx_let, I’ve been doing that on BuckleScript projects without any problem.

#10

How? With infix operators? Cheng Lou says they‘d like to avoid them in Belt, so I guess as a good citizen, I’d like to try and avoid them too.

#11

I’m using infix operators, and it’s working great. I can’t imagine writing the long pipelines without them. I miss ppx_let though, but I’m hoping I can use it in BS projects soon.

#12

Is Let_anything inferior to pxx_let?