ErrorValues! Thank you! This is exactly what I was looking for. Post: https://blog.golang.org/errors-are-values https://blog.golang.org/errors-are-values > but

ErrorValues! Thank you! This is exactly what I was looking for. Post: https://blog.golang.org/errors-are-values https://blog.golang.org/errors-are-values > but readability is poor when every error must be handled many times instead of implicitly returning to callers. I should clarify that I'm only using these types for parsing and transformation pipelines and not as a general replacement for exception handling—in other words only in places where you'd have to already worry about undefineds, nulls, and NaNs.