Hacker News Reader

Comment by monocasa | Hacker News Reader

I really don't like this whole "screw the type system, just throw string errors that you don't know the type of" behind all of this. It feels like backporting golang's error handling to rust, which feels like a step backwards.

View on HN

Some factors for this

- When prototyping, deferring worrying about exact error types is helpful

- In applications, you aggregate so many types of errors, sometimes it is easier just to dynamically accept any.

For sure.

1 - Just have a Todo(String) in your error enum while prototyping. Remove it as you clean up a prototype, and you get a nice set of compiler errors telling you everywhere that needs to change.

2 - If you're aggregating so many error types that it's unwieldy, you're probably doing to much in one place. That has all sorts of down stream issues with testability and what not. Hacking your error types to make it easier is probably not the best option.

> 2 - If you're aggregating so many error types that it's unwieldy, you're probably doing to much in one place. That has all sorts of down stream issues with testability and what not. Hacking your error types to make it easier is probably not the best option.

I'd disagree. In a static-site-generator, I need to deal with

- file format errors

- syntax highlighting errors

- io errors

- Template language errors

- Adhoc errors I construct throughout the application

- Regex errors

- RSS errors

- jsonfeed errors

- sitemap errors

- git errors

Without even getting into any errors from the webserver that is being run. Yes, I could carefully construct an error enum for each subsection of the application and bubble those up ... but why? I'm not programmatically acting on these but sending them up to the user.

By dumping all those together, you've lost context as to why or where these errors have come from. Just yolo displaying io errors is a terrible experience for your users.

That's a really unfair characterization of Go's error handling, and something only really novice Go developers do.

https://dave.cheney.net/2016/04/27/dont-just-check-errors-ha...

I've been using Go for 7 years and I don't think this is a mischaracterization at all. I definitely don't think it's something "only really novice Go developers do"--I see it all the time, including in popular open source libraries and even the standard library. I don't think it's contentious that Go's error handling needs some improvement (by which I mean "more standard, structured error handling" and not "syntax support for eliminating error handling boilerplate"--the latter is more contentious as far as I'm aware).

And pretty much every production golang codebase I've seen.

Every time you use `fmt.Errorf` and `if err != nil { return nil, err }`, you're returning a stringly typed error up the stack.

The entire stdlib does this. An error stack is never present from stdlib functions' errors, and third party libraries I see it just as infrequently.

If only novice go devs do that, than the entire go core team are novices, as well as the authors of popular go projects like kubernetes and docker.

"Stringly typed" means literally a string. Go doesn't always distinguish between errors, but the error type does distinguish errors from non-errors and that's important.

It seems better to have coarse-grained types than to standardize the wrong type hierarchy?

Almost every large Go codebase does this with very few exceptions. Until the advent of github.com/pkg/errors there wasn't an easy way to uniformly implement error chaining so people would just prepend strings (if they have any context at all) and used fmt.Errorf religiously. These days, fmt.Errorf is still used but now you can in principle root-cause errors with errors.Cause -- unfortunately many Go libraries do not use github.com/pkg/errors (because of the nested vendor problem that existed for many years) and so you are stuck if you want to root-cause an error in an older library.

All of that being said, modern Go (written in the past few years) could avoid these pitfalls. But very few production codebases were both written in the past few years and only use libraries written in the past few years.

I've worked on Go codebases for the past 5-6 years.

Even some std packages do it.

The std lib is not the paragon of go virtue as some people make it out to be. The maintainers have been frank with some of the mistakes and things they'd do differently now but because they place the Go 1 promise above everything else (a good thing), it has some patterns not many would recommend these days, error handling among them.

And kubernetes, docker, golang.com/x/*, etc.

And it's not like they couldn't add better types to errors without breaking backwards compat. Returning a type that implements error instead of fmt.Errorf doesn't break existing semantics.

Reply on news.ycombinator.com