Go Error Handling: Annoying or Awesome?

Ryan Kikayi — Mon, 25 May 2026 07:40:27 +0000

For weeks when I was completely new to coding,I would always keep wondering; "What did I get myself into?", barely understanding what I'm looking at whenever I come across code that looked like this:

file, err := os.Open("data.txt")
if err != nil {
    log.Fatal(err)
}

data, err := io.ReadAll(file)
if err != nil {
    log.Fatal(err)
}

var result MyStruct
err = json.Unmarshal(data, &result)
if err != nil {
    log.Fatal(err)
}

And for some reason it just did not make any sense to me at first; what do you mean we're using 9 lines of code just for error checking - has to be a joke?!
Over at YouTube, no tutorial was relatable. I mean there were tutorials on error checking for python, and javascript, but the concept wasn't just sticking.
Eventually, I ended up just copying chunks of code that I barely understood and pasted them into mine. Function returns two things, assign them to a variable and err. Basically pasting the if err != nil block was what I knew I was doing, the reason why? Not so much.
I wasn't reading the error half of the time, I was just calling log.Fatal(err) hoping it would never have to run.

Later on after getting comfortable with the language, I decided to work on a personal project - a CLI tool that reads config files, makes API calls, and writes its output to disk. Unfortunately, it broke in production, the problem;

data, _ := json.Marshal(payload)

I had used a blank identifier _ to ignore the error completely - a habit I discovered to avoid having to write the check. This caused an API call to fail silently because the marshal was sending an empty body, and the API was rejecting it. And there I was, trying to debug something a single error message would have told me immediately.
I realized, in Go errors are not exceptions, they're values - like regular data, a functions gives back to you. When you call a function that can fail, it returns two things; the result, and an error. Go hands you the error and trusts you to deal with it. So basically, writing if err != nil is like saying "Something could go wrong here. What do you want to do about it?" in Go. Once I finally understood that I started seeing them as decision points.

So how do you actually make peace with it?

Early on, I used to write my errors the same: log.Fatal(err). When something broke, I'd get a vague message like unexpected end of JSON input with zero context about where in my program it came from.
The fix was wrapping errors with context using fmt.Errorf :

data, err := io.ReadAll(file)
if err != nil {
    return fmt.Errorf("failed to read config file: %w", err)
}

The %w keeps the original error intact so you can still inspect it, but now every error message tells you what your program was trying to do when it failed. That one change made debugging significantly less painful.
The second thing that helped was setting up a snippet in my editor. In VS Code, typing ife and hitting Tab expands to:

if err != nil {
    return err
}

The official Go extension already includes this — check your snippet settings if you haven't already. It sounds like a small thing, but when you're writing the pattern twenty times a day, not having to type it from scratch every time genuinely reduces the friction.

So — annoying or awesome?

Honestly? Both. Annoying at first, awesome once you understand why it exists.
Go made a deliberate choice to make error handling visible and local, rather than something that silently bubbles up through your stack and crashes things in ways you didn't expect. Every if err != nil is a decision point baked directly into your code. You always know where an error came from. You always have to decide what to do with it.
For a first language, that turned out to be a surprisingly good environment to learn in. I couldn't ignore problems — Go wouldn't let me. And when things went wrong, the error was almost always exactly where Go said it was.
Would I have picked a different first language if someone had warned me about this pattern? Maybe. Am I glad I stuck with Go? Absolutely.

If you're learning Go right now, I'm curious — what part of the language caught you off guard the most? Drop it in the comments.

Vibe Coding is a Last Resort Mistake!!

Ryan Kikayi — Thu, 12 Feb 2026 09:31:38 +0000

We've all been there. You're deep into a project, making great progress, and then you hit a wall. Maybe the app is having trouble reading data from the API, or your code for handling mistakes feels messy and confusing.
Instead of reaching for the official docs, you reach for the AI—your "coding genius."
That was my first big mistake.
Ten minutes later, all my clean, manual progress was gone. The AI had:

Restructured my structs without asking.
Injected unnecessary pointers that made no sense.
Turned my logic into a "hallucinated" masterpiece that wouldn't even run.

I didn’t realize it then, but I had fallen into the trap. I barely understood what was happening in my own file. It became a frantic back-and-forth conversation with ChatGPT where all I was doing was prompting, copying error messages, and pasting code. We all know how the copy-paste game ends.

How I Saved the Project:

To save my work, I had to stop the cycle. I was the victim, and my project was the casualty. To get back on track from that AI-generated mess, I had to take these steps:

The Hard Reset I had to go back to my last working version. If you aren't using Git yet, let this be your wake-up call. Being able to "undo" a hallucination is the ultimate safety net. I opened my terminal and ran:

bash
# This command resets your file to the last saved version
git checkout -- weather_app.go

Just like that, the AI "slop" was gone, and my original logic was back.

Surgical Prompting I stopped giving the AI my entire file. I isolated one specific logic block and asked: "Why is this specific line throwing an error?"
Verification Once the AI suggested a solution, I verified it using outside resources like StackOverflow and the Official Go Docs. This helped me actually learn the why behind the fix.
The "No-Paste" Rule Instead of pasting the code directly, I forced myself to manually type the solution back into my editor. This rebuilt the mental connection between my brain and the screen.

The "S.P.E.C." Framework:

From this encounter, I’ve learned that AI should be your last resort, not your first move when you hit a dead end. To keep your code from turning into "Slop," follow this framework:

S - Scope: Give the AI only the snippet it needs. "Only edit the FetchWeather function."
P - Parameters: Explicitly tell it: "Use only standard libraries."
E - Edge Cases: Ask: "How should this handle a 404 or a timeout?"
C - Constraints: Be firm: "Do not change my existing struct definitions."

Final Thoughts:

In 2026, anyone can prompt, but not everyone can engineer.
Don't let AI be the lead architect of your learning journey. Use it as a pair programmer that requires strict instructions. The moment you stop understanding what you're doing or what is on your screen—stop.
Go back to your original code, follow the framework, and stay in control of your logic.

DEV Community: Ryan Kikayi

Go Error Handling: Annoying or Awesome?

Vibe Coding is a Last Resort Mistake!!

How I Saved the Project:

The "S.P.E.C." Framework:

Final Thoughts: