In Go 1.13, an API for error type inspection was introduced. This provides a way to communicate different types of
errors. Why would you want to do this? A common example to distinguish an error that can be trivially handled with a
retry, such as updating a network resource using a compare-and-set operation, vs a non-retryable error (authentication
failed). However, 1.13 API does not help in error printing. I actually spent a bit of time trying to coerce the API into
exposing the call stack information, but failed to do so without also exposing unwanted error types. You can see my failed attempt here.
hide/change the error type when annotating an error
hard to do, so “no”
The last feature is particularly important. It allows one to expose the call stack to aid in debugging without
encouraging programmers to code against implementation details.
Some programmers will code against implementation details no matter what you do.
A new model for content creators?
I followed Bleve for a while. The lead of Bleve, Marty Schoch, had started a new group called Bluge Labs. By the
means of this project, I learned that you can create a sponsorship model on Github. It is an interesting model and
I’m curious to see how it turns out. Sponsorship often distorts the relationship between two parties. I hope it works
out for Mr. Schoch.