Skip to main content

Error handling in GO, my thoughts.


Go's error handling emphasizes simplicity and explicitness. 


This post explores its unique approach and compares it to other languages.

Agenda 

  • Why is it an interesting topic in GO?
  • What do we have in different languages?
  • It is why you can trust.

Why is it an interesting topic in GO?

I like having control over the processing of the source code; that code has a clear and structured flow, and it helps to read and understand the code and what's going on here. GO has it. And that's all that GO has. You are limited to processing it ONLY in this way. GO developers are discussing that it is a problem that you need to write each time mechanism to validate the error state and handle it on each layer of the process flow. And YES, it is noisy, I totally agree here. But when I saw this discussion, only one thing in my head. Did you try to debug the bug when you can't see where and who throws this exception? Yeah, it is the wrong implementation, but in my experience, I saw it very difficult to build such a process for all types of exceptions (we are back to tonnes of code, but in this case, this processor is doing more than it should).

What do we have in different languages?

.NET, Java, and JS have strong mechanisms to process errors it is the exception. So, you can control error processing by that. How? We have a "try, catch, and throw" mechanism or code flow to create and handle errors. So, if you want to create an error and notify the caller, then you can throw the exception. It can be a specific type of exception or a base exception with a specific error message. It is a powerful mechanism because you have control and flexibility. But, again, I saw examples where developers try to do that everywhere, for technical, business, and validation errors. I totally forgot about the performance, as well. Because exception processing is hard from the resource usage side. Catch exceptions can allocated in one place, you can miss something, and the code will have a "small."

It is why you can trust.

Evidence, evidence, and evidence. You can find the project and try it yourself and see the results. My GitHub repository with these testing with GO and .NET projects to compare results: https://github.com/kolomiietsmykola/ErrorHandleBenchmark

Outputs


Please share your comments or concerns about it in the comments!


Comments

Post a Comment

Popular posts from this blog

Why Microsoft Azure Well-Architected Framework Can Improve Architecture

Small and medium-sized businesses often face a common challenge: the absence of experienced cloud engineers. Due to limited resources, teams typically choose the quickest path—getting things done in the easiest, fastest way. Unfortunately, this approach often leads to solutions that aren't secure, cost too much, and become nearly impossible to extend or manage effectively. Recognizing this critical challenge, Microsoft Azure has developed the Well-Architected Framework. This comprehensive set of guidelines and best practices helps businesses assess their existing solutions and guides them toward building robust, secure, cost-effective, and manageable cloud infrastructures from the start. The Azure Well-Architected Framework is structured around five essential pillars: Cost Optimization : Ensuring that cloud resources are used efficiently and effectively, reducing unnecessary expenses. Operational Excellence : Focusing on the ability to run and monitor systems effectively, ensuring ...
2 comments
Read more

"Dushnylo" Series: Monolith First approach.

I keep hearing, “You MUST start with a monolith.” Every new project? Always? When I hear that, two thoughts immediately come to mind:      1️⃣ “It depends.” You can’t just blindly say every project must start as a monolith.      2️⃣ My inner Dushnylo whispers: “Time to make a post about this.” So, here’s my take: I disagree. Not only do I disagree, but I believe the most critical and dangerous part of system design is analyzing and understanding business needs before making architectural decisions. Why? Simple. Imagine you’re building a streaming platform that processes massive amounts of data, handles notifications, and integrates with third-party services. Does this sound like something you’d build as a pure monolith? Of course not. But I do agree on one thing—you have to start somewhere. That starting point could be a simple core application —yes, it might look like a monolith at first. But you’re not designing the entire system as a monolith. ...
Post a Comment
Read more

First Look at Cerbos: A Solution for Dynamic Role & Permission Management

Introduce My next post is about tools for managing roles and dynamically controlling access to resources. Some business requirements demand extreme flexibility, often requiring a combination of RBAC + ABAC at the same time. From my experience, I’ve seen a lot of solutions, but most don’t cover all the key points. There are three circles that are really hard to combine: Performance, Security, and Flexibility . And when someone tries to implement all three—oh, it’s painful. But I found a technology that (almost) solves this challenge: Cerbos —a scalable, open-source authorization layer for handling roles and permissions. ( Cerbos site ) Why is it good? ✅ Centralized configuration – Everything is managed in one place. ✅ Easy integration – SDKs are available for all popular languages:     ðŸ”¹ .NET, Go, Java, JS, PHP, Python, Ruby, Rust ✅ Great documentation – Clear examples and guidance. ✅ Playground for testing – No need to run an app or set up tools. Just te...
Post a Comment
Read more