Comment by mjevans

Comment by mjevans 9 days ago

11 replies

View on Hacker News

Go / golang added https://pkg.go.dev/errors

Which includes nested / stacked errors and helper functions for checking them.

It doesn't implement error classes, but you can create a stacked chain of errors which achieves the same sort of 'Handle a classification of error' (anything which includes that class).

Older libraries don't use these features, as far as I know. So it's sort of like the half-baked enumerate everything sort of generic functions that older stable versions (like on hacker rank) ship.

euroderf 9 days ago

The %w printf verb. It yields much more than a stack dump. Get meaningful error annotations from every step back up the callstack.

Reply View 0 replies
vlovich123 9 days ago

I think you missed my complaint was that unlike more modern languages like Rust, Go has way too much boilerplate for error handling and not only does it not have error chaining via a `?` operator, it doesn’t even force you to check the error meaning I’m sure there’s plenty of missed error checks in production code leaving all sorts of vulnerabilities lying around. The package you linked in no way addresses what I wrote.

Reply View 9 replies
  • gwd 9 days ago

    > have error chaining via a `?` operator

    Although I do frequently find typing in the boiler plate of _every_ _single_ _error_ a bit of a faff, it does prompt me each time to really think "what if an error really happened here". I'm inclined to think that something like the ? operator makes it much easier to just toss in the ? and not consider the implications of an error.

    > even force you to check the error[,] meaning I’m sure there’s plenty of missed error checks in production code

    Something the equivalent of "#[must_use]" would certainly be an additional aid, (as would const pointers).

    EDIT but one of the tools mentioned in the blog post, golangci-lint, will warn you of unchecked errors.

    Reply View 5 replies
    • vlovich123 9 days ago

      You’d really like the C community. They like to say things like “although I do find the setfaults annoying, it really makes me think carefully about memory ownership and layout”. The problem is that if you don’t have a consistent way to accomplish a task correctly, something like errors that could happen a nearly every function call, then you’re very likely to make a mistake. Coupled with that, most people ignore testing for error conditions or simulating errors, so the error handling has a very high likelihood of having bugs.

      Reply View 4 replies
      • gwd 8 days ago

        > Coupled with that, most people ignore testing for error conditions or simulating errors, so the error handling has a very high likelihood of having bugs.

        Er, is Rust any different in that regard? As I said, I tend to think the `?` operator would make that worse, as the error path is so much less visible. In Golang if you don't test your error path, at least it will be listed as having no coverage -- is the same thing true in Rust?

        Reply View 2 replies
      • randomdata 8 days ago

        > The problem is that if you don’t have a consistent way to accomplish a task correctly

        I know of no programming language that provides a consistent way to deal with values correctly, if the venerable if statement (or whatever is equivalent) is not it.

        What is this magical fairy language that you speak of or envision?

        Reply View 0 replies
  • mjevans 9 days ago

    I've been interested in learning more about Rust, but so far haven't had a project that seemed like it'd be worth learning a whole new language structure.

    So, I was responding to my _understanding_ of what you had written, which apparently didn't adequately explain what you sought to those who haven't seen the thing you were trying to reference.

    I do occasionally use a helper function in golang like 'nilOrPanic()' which if it's given an Error type that isn't nil causes a panic(); which isn't so useful outside of development or toy exercises.

    Reply View 1 reply
    • vlovich123 9 days ago

      A language like Rust makes the Error and Option types first-class. It’ll be a compiler warning (or error? Don’t remember right now) if you ignore the return from a function that returns one of these. Go requires a separate linter and relies on uncaught variables. Minor distinction but important one because defaults matter.

      If you want to panic on error/option (i.e. you don’t think it’s going to happen), you add an exclamation mark after the error. If you want to unwrap but propagate the error effortlessly, add a question mark. This syntactic sugar is a pretty common ideas at this point not unique to Rust. What is a bit more unique is that Error and Option are sum types. This means that you can’t just access the value without unwrapping them somehow and unwrapping requires you to either handle the error by a match or conditional statement, propagate (?), or panic (calling .unwrap() function). But you have to make that decision and can’t ignore it so while you have to think about what you want the error handling to look like, you can’t ever accidentally forget (& since mostly you forward, ? Makes things easy even if you need to bridge different error types).

      Reply View 0 replies
  • nitely 9 days ago

    They are going to add boilerplate free error handling sooner or later. There are many proposals for "Go 2" already.

    Reply View 0 replies