1. 12
    Check for Go Errors go sigusr2.net
  1.  

  2. 3

    Ah, heck, I like this a lot.

    Even though it doesn’t reduce all the noise, it reduces a lot of bulk and I’m even a fan of the check(bool) notion. It also means good errors and better ability to check constraints at the top of functions. All while still respecting error types as real error types.

    1. 1

      I like it, too. Maybe I should float it…

      It’d just be nice to have experience with it, and I don’t have time right now to make a prototype using code transformation, or something. Though, there is already a try prototype, maybe it wouldn’t be that hard to modify…

    2. 3

      My main issue with “check” is that producing an error description via string concatenation loses all the structural information your errors held.

      Errors with added context should preserve details like the stack trace (each time you wrap the error adding another one), but also structured data (eg the size of the file that failed to write, the parameters to your query builder that resulted in a query timeout, etc). Without this structured data it’s hard to query stored error logs.

      1. 1

        is that producing an error description via string concatenation loses all the structural information your errors held.

        This is a problem, today. pkg/errors.Wrap* provides formatting, but I’d keep that out in favor of fmt.Sprintf at the call site. check would definitely do Wrapping of some kind to preserve stack trace information. I have never heard of structured data in errors, but it sounds like a cool idea—link to more information about how you use it/library?

        Also, that’s unlikely to be part of Go’s chosen improved error handling given I don’t remember seeing mention of it it the Wrap discussion, and haven’t seen it in this one… Has it been proposed somewhere?

        1. 1

          I think it belongs in the application rather than the language. Needs vary considerably, and storing every call site is expensive in some cases. I haven’t used this technique in go (or anything open source) before.

          It’s especially important for software that is sold to enterprises for them to run in house, with a support contract.

          Such software needs things like I18n for user visible error messages. In that case you want every error type to have a unique code for diagnosis, structured data to fill out the message, and leave the rest for the presentation layer. You also want errors (even handled ones) to be shipped somewhere for analysis, subject to organisational constraints around data control.