Error Handling

Golang API Design - Illustration depicting a clear and safe API design for Go

[Golang] Stop Returning `(nil, nil)` in Go: A Small API Design Choice That Prevents Big Bugs

When designing Go APIs, you might think it’s harmless to return (nil, nil) when an object isn’t found. Many developers do this because it feels like “not found” shouldn’t be treated as an error. However, this approach often leads to one of the most frustrating runtime crashes in Go: panic: invalid memory address or nil pointer dereference In this post, we’ll cover: The problem — how (nil, nil) breeds fragile code Why this design creates real-world headaches Two solutions: Best practice (recommended): return a predefined error instead Alternative pattern: use an explicit existence flag An evolved, safer version of the code The goal isn’t just to fix mistakes, but to enhance API design to prevent misuse down the line. ...

The Pragmatic Way to Handle Multiple Errors in Go (Before and After Go 1.20)

Introduction For many Go developers, a recurring challenge has been: “What is the right way to handle multiple errors?” Whether it’s running several cleanup steps, processing batches of data, or validating various inputs, ensuring errors are handled correctly and efficiently has been crucial. Before Go 1.20, developers did not have a unified approach; each team created its own solution, often leading to awkward, unidiomatic, or even incorrect patterns. With Go 1.20, we now have a standard, pragmatic solution: errors.Join. This article will explore why older techniques were problematic, how the Go team designed a better approach, and how to apply this new solution effectively in your code. ...

Golang timeout feature - Illustration depicting a clock and a task symbolizing the implementation of a timeout feature in Golang

[Golang] Implementing Timeout Feature in Golang for Efficient Task Processing and Error Handling

Let’s dive into an exciting scenario to explore how we can jazz up our Golang code with a cool timeout feature! Imagine this: you’re building an awesome application and you want to delegate a task to a third-party API. But here’s the catch - the processing time for this task is unpredictable. To add some spice to the mix, you decide to set a timeout for the task. If the third-party API takes too long and doesn’t return the result within the timeout, we’ll label it as error and move on, regardless of whether it eventually responds or not. We’re all about efficiency here! However, if the API does manage to return the result within the timeout, we’ll update the task status accordingly. ...