DEV Community

JavaScript: Handling errors like Go

Eduardo Rabelo on November 08, 2018

Back in August, I wrote an article in Brazilian-Portuguese explaining how I use async/await to isolate error handling. Today I'll translate it to ...

Read full post

rhymes • Nov 8 '18

Hi Eduardo, nice example but there are a couple of things that make me unconvinced this is the best approach in JavaScript:

JS wasn't designed to have a Go style of exceptions
in your example the error you pass on could be generated by .fetch() or by .json() and it's not going to be clear inside the main function

Eduardo Rabelo • Nov 8 '18

how are you rhymes? thanks for your comment!

JS wasn't designed to have a Go style of exceptions

not discussing the way the language handles side-effects (golang is built-in and javascript you need to wrap it in something like shown in this article), my personal experience is: it's just a matter of interface response pattern

i've being using it for node.js, typescript, flowtype, you name it... and it works pretty well, is just another pattern inside your codebase

in your example the error you pass on could be generated by .fetch() or by .json() and it's not going to be clear inside the main function

there is nothing preventing you to massage these responses... you can easily branch it in the catch:

api.getRandomDog = async () => {
  try {
    let res = await fetch(url);
    let json = await res.json();
    return [null, json];
  } catch (err) {
    if (err === "fetch-error") {
      return ["fetch-error", null]
    }
    if (err === "json-error") {
      return ["json-error", null]
    }
  }
};

in the same way you can inspect the error in the main function:

async function main() {
  let [err, res] = await api.getRandomDog();

  if (err === "fetch-error") {
    // handle fetch error
  }

  if (err === "json-error") {
    // handle json error
  }

  // do something with `res`
}

use your imagination, but be consistent! :) ... is rare when we need to have these granular error handling in the front-end... in my perspective, your back-end should be handling it (checking for missing params, not found user, credentials, etc)...

in an node.js/express world, your error middleware would be responsible for these branches and the client response/rejection could be only one!

many thanks 👋

rhymes • Nov 8 '18 • Edited

how are you rhymes? thanks for your comment!

well thanks :D hope the same for you

i've being using it for node.js, typescript, flowtype, you name it... and it works pretty well, is just another pattern inside your codebase

Sure, I'm not against it, it's just that in a way you're limited to your perimeter of code, I wouldn't use it in a third party library. Most JS developers expect failure to be escalated to an exception so that if it's synchronous it can be caught and if it's async it can be handled. If suddenly you start returning two-valued arrays you're changing a silent contract. See how complicated it's going to be to change the way Go error handling is done. And Go is nowhere near as popular as JS.

It's not a bad idea inside an app though, as you say, if it's used consistently.

Thank you for your perspective!

Mohammad Aziz • Nov 8 '18 • Edited

I have a question, even though this blog post is about Node.js, I have a question about Go.

How can you mimic Promise.all() in Go? What would be equivalent code in Go?

async function main() {
  // Assume all db calls will return a promise
  const firstUserPromise = firstDbCall().then((res) => res);
  const secondUserPromise = secondDbCall().then((res) => res);
  const thridUserPromise = thridDbCall().then((res) => res);

  const [
    firstUserData,
    secondUserData,
    thirdUserData
  ] = await Promise.all([firstUserPromise, secondUserPromise, thirdUserPromise]);
}

rhymes • Nov 8 '18

You probably need to use a WaitGroup.

This is the example you can find in the documentation link:

package main

import (
    "sync"
)

type httpPkg struct{}

func (httpPkg) Get(url string) {}

var http httpPkg

func main() {
    var wg sync.WaitGroup
    var urls = []string{
        "http://www.golang.org/",
        "http://www.google.com/",
        "http://www.somestupidname.com/",
    }
    for _, url := range urls {
        // Increment the WaitGroup counter.
        wg.Add(1)
        // Launch a goroutine to fetch the URL.
        go func(url string) {
            // Decrement the counter when the goroutine completes.
            defer wg.Done()
            // Fetch the URL.
            http.Get(url)
        }(url)
    }
    // Wait for all HTTP fetches to complete.
    wg.Wait()
}

Mohammad Aziz • Nov 8 '18

I was not aware of WaitGroup. Thanks!

Forest Hoffman • Nov 8 '18

WaitGroup is awesome 🎉

Eduardo Rabelo • Nov 8 '18

funny enough, in Go is a little bit harder to do the exactly same!

i recommend you to go through two blog posts:

you will need to use channels/goroutines to achieve the same.. as said by rhymes in this thread, you will need to use WaitGroup!

there's a merge function in the documentation link of item 1 above, where using it, you can do something like this:

func makeRequest(url string) <-chan string {
    res := make(chan string)

    go func() {
        res <- "Request started..."

        _, err := http.Get(url)

        if err != nil {
            res <- "Failed."
        }

        res <- "Done!"
        close(res)
    }()

    return res
}

func main() {
    c1 := makeRequest("https://google.com/")
    c2 := makeRequest("https://twitter.com/")

    for n := range merge(c1, c2) {
        fmt.Println(n)
    }
}

running it will print:

$ go run main.go 
Request started...
Request started...
Done!
Done!

i've been using it since I discovered it :)

Theofanis Despoudis • Mar 30 '19

I think you can also use errgroup to handle errors gracefully

Mohammad Aziz • Nov 8 '18

This looks simple and powerful. Probably I'll have to dig deeper to understand it. Thanks for the resources.

Jannis Jorre • Nov 8 '18

Thanks for the post! I think this is a great pattern to follow.

I have one question left: is there a reason you return the error as first item and not the requested end-value?😇

Eduardo Rabelo • Nov 8 '18 • Edited

thanks for your time Jannis! :)

my first approach was to mimic the Go way, but after it "clicked", I started using it in different ways!

🤗

Jannis Jorre • Nov 8 '18

Is there a reason though?🤔

Eduardo Rabelo • Nov 8 '18

the reason was to mimic Go... after switching between JavaScript and Go projects, I felt the need to try to write in a similar way in JavaScript :P

Jannis Jorre • Nov 9 '18

I got that - sorry if I wasn't clear enough, let me rephrase my question:

Is there a reason to go for a return that can be destructered as [err, value] over one that would be destructered with [value, err]?

I hope I made it understandable now.😇