4 Open-Source Security Tools Every Dev Should Know

Hello, I'm Maneshwar. I'm building git-lrc, a Micro AI code reviewer that runs on every commit. It is free and source-available on Github. Star Us to help devs discover the project. Do give it a try and share your feedback for improving the product.

So you wrote your first Go program. It compiled. You felt powerful. Then you saw this:

file, err := os.Open("dreams.txt")
if err != nil {
 return err
}
defer file.Close()

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

result, err := process(data)
if err != nil {
 return err
}

And you thought: "Wait... am I supposed to write if err != nil for the rest of my life?"

Yes, you are. But hear me out, it's actually kind of beautiful once you stop fighting it.

Why Go Did This To You (And Why It's Actually Fine)

Other languages treat errors like that one friend who shows up uninvited to your birthday party. They appear out of nowhere, ruin everything, and somebody else has to deal with them.

Go decided: errors are values. They're just things. Like strings. Or integers.

This means:

• ✅ Errors are visible in the function signature

• ✅ You can't accidentally ignore them (well, you can, but the linter will judge you)

• ✅ No invisible control flow jumping across 14 stack frames

• ❌ You have to type if err != nil approximately 9,000 times

It's a tradeoff. You'll grow to appreciate it. Or you'll switch to Rust. Both are valid.

Pattern 1: Just Return It

func loadConfig(path string) (*Config, error) {
 data, err := os.ReadFile(path)
 if err != nil {
 return nil, err
 }

 var cfg Config
 if err := json.Unmarshal(data, &cfg); err != nil {
 return nil, err
 }

 return &cfg, nil
}

When to use it: When you have nothing useful to add and the caller already has enough context.

When NOT to use it: When the caller is going to see unexpected end of JSON input and have absolutely no idea which of the 47 JSON files in your app caused it.

Pattern 2: Wrap It Like It's 1999

fmt.Errorf with %w. This is your new best friend. Treat them well.

func loadConfig(path string) (*Config, error) {
 data, err := os.ReadFile(path)
 if err != nil {
 return nil, fmt.Errorf("loadConfig: reading %s: %w", path, err)
 }

 var cfg Config
 if err := json.Unmarshal(data, &cfg); err != nil {
 return nil, fmt.Errorf("loadConfig: parsing %s: %w", path, err)
 }

 return &cfg, nil
}

Now when this fails, you get something like:

loadConfig: parsing /etc/app/config.json: unexpected end of JSON input

The %w verb wraps the error so callers can still inspect it with errors.Is and errors.As.

Use %v instead and you've turned your error into a string.

The error has been murdered. You are the murderer.

Pattern 3: Sentinel Errors (The Named Ones)

Sometimes you want callers to check for specific errors:

var (
 ErrNotFound = errors.New("user: not found")
 ErrUnauthorized = errors.New("user: unauthorized")
 ErrRateLimited = errors.New("user: rate limited, chill out")
)

func GetUser(id string) (*User, error) {
 if id == "" {
 return nil, ErrNotFound
 }
 // ...
}

And the caller does:

user, err := GetUser(id)
if errors.Is(err, ErrNotFound) {
 return c.JSON(404, "user not found")
}
if err != nil {
 return c.JSON(500, "something exploded")
}

errors.Is walks the wrap chain, so even if the error got wrapped 12 times on its journey, you can still identify it. It's like DNA testing for errors.

Pattern 4: Custom Error Types (When You're Feeling Fancy)

Sometimes a string isn't enough. You want to attach data. You want a struct. You want to flex.

type ValidationError struct {
 Field string
 Message string
}

func (e *ValidationError) Error() string {
 return fmt.Sprintf("validation failed on %s: %s", e.Field, e.Message)
}

func validateEmail(email string) error {
 if !strings.Contains(email, "@") {
 return &ValidationError{
 Field: "email",
 Message: "missing @ symbol, are you okay?",
 }
 }
 return nil
}

And the caller pulls out the type:

err := validateEmail(input)
var vErr *ValidationError
if errors.As(err, &vErr) {
 fmt.Printf("Hey, your %s is broken: %s\n", vErr.Field, vErr.Message)
}

errors.As is errors.Is's overachieving cousin. It doesn't just check, it extracts.

Pattern 5: panic and recover (The Forbidden Techniques)

You may have heard of panic. Maybe you saw it in a library and felt a chill.

Rule of thumb: If you're panicking, you should probably be returning an error instead.

Real exceptions to the rule:

• Truly unrecoverable situations (corrupt program state)

• init() functions where the program literally can't start

• Inside your own package, where you recover() at the boundary and convert to an error

func MustCompile(pattern string) *Regexp {
 re, err := Compile(pattern)
 if err != nil {
 panic(err) // genuinely fatal at startup
 }
 return re
}

If you're using panic for normal control flow, the Go gophers will find you. They have ways.

TL;DR For The Scrollers

SituationUse ThisJust bubbling it up with no extra inforeturn errWant to add contextfmt.Errorf("doing X: %w", err)Caller needs to check a specific errorSentinel error + errors.IsCaller needs error dataCustom type + errors.AsThe world is endingpanic (sparingly!)

Final Thoughts

Yes, you'll write if err != nil a lot.

But here's the thing, once you stop seeing it as boilerplate and start seeing it as a decision point, every one of those blocks becomes a tiny little moment where you, the developer, get to think: "What does failure mean here? What does the caller need to know?"

That's not a burden. That's craftsmanship.

Now go forth and wrap your errors.

If you enjoyed this, drop a 🦫 in the comments. If you didn't, write if err != nil { return err } 100 times as penance.

AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs -- without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.*

Any feedback or contributors are welcome! It's online, source-available, and ready for anyone to use.

Try it, and⭐ Star it on GitHub