One of the bugs I was tasked to solve at my #dayjob the second week there seemed simple on the surface. Potential applicants (aka leads), need to be submitted to the company wide server. The lead was original stored in our team's database so we'd ret...

Primal Skill

George

Ethical AI

Community Picks is a section on daily.dev where our community members share the most interesting and valuable content they've discovered online. From insightful articles to handy tools, every post is a gem curated by our dedicated coomunity. To contribute to Community Picks, you need to have at least 250 reputation points, ensuring that only active and trusted members can share their finds.

Community Picks

A developer shares their experience solving a bug where lead data submissions occasionally missed phone and email information due to null pointers. Instead of simple validation checks, the article advocates for using parsing to ensure type safety and more reliable error handling. By creating new types that inherently handle potential errors, the code can prevent issues at their origin and improve overall bug-freeness and clarity.

Go Parse, Don't Validate

Nice solution, it’s an interesting way to think. Thanks for sharing it!
Personally, I didn’t like it very much. I feel that creating types to represent very specific types of data (like an array with 3 items, or an email) is overcomplicating a problem that can be solved with basic validations like <code>len(arr) &gt;= 3</code> and may be less memory efficient, but I’m not sure.
I get that it has its benefits, and seems more like an object-oriented approach, but my personal preference is always for procedural programming.

To me, this looks a bit like the Rust way of communicating errors, which i really like. However, in Rust, you’d probably use a Result&lt;&gt; and an enum describing the error, which, IMHO, is much more concise.
Go can’t go this route due to the lack of real enum types, so i can understand the decision to use types instead. However, as <a href="https://app.daily.dev/henriqueleite42" data-mention-id="sbsMzAwu73ZnbXGf5ETGJ" data-mention-username="henriqueleite42">@henriqueleite42</a> already mentioned, this might be less memory efficient. Also, i think this approach will get very complicated in complex validation scenarios.

We’d make a great duo, since I love tracking down bugs, but only slightly like implementing new features. Nothing beats a PR where the only change is a removed exclamation mark.