Seeking council: Would a PR changing error type be accepted ?

[cjdelisle]

I wanted to ask before making the PR itself because making it will take a bit of time. Background:

• Golang error doesn't have stack traces and it should.
• Replacing golang native errors with a new error structure allows stack traces
• However, the change is highly invasive
• For me, it's an absolute necessity to have stack traces in order to work, for you it's not because you got this far - so it might not be worth it
• The change is arguably anti-go because it subverts the golang error handling custom, it will also make it more difficult for new go developers to get up to speed on the project

For the meat and potatos:

• error is replaced with er.R https://github.com/pkt-cash/pktd/blob/master/btcutil/er/er.go
• every call to errors.Errorf() becomes er.Errorf()
• errors.New() becomes er.New()
• Any time an outside codebase is called and returns an error, that error is wrapped using er.E() and it becomes and er.R
• Typed errors look like this: https://github.com/pkt-cash/pktd/blob/master/neutrino/errors.go#L7
  1. Define your error class: var Err er.ErrorType = er.NewErrorType("neutrino.Err")
  2. Define your error codes within that class: ErrGetUtxoCancelled = Err.CodeWithDetail("ErrGetUtxoCancelled", "get utxo request cancelled")
  3. Check if an er.R is an instance of an error code: if ruleerror.ErrBadCheckpoint.Is(err) {
  4. Check if an er.R is an instance of any code in an error class: if !ruleerror.Err.Is(err) {

And now all errors String() to include the name and code (if applicable) and the stack trace.

Is it slower? Certainly yes, by how much I didn't measure, but once this is implemented, any amount of it can be optimized or turned off by simply going into the er.go file.

I want to know what people think before taking the idea any further.

[Crypt-iQ]

I can't speak for everyone, but I would say no. I'd prefer to not have highly invasive code changes to the codebase. Would also hurt readability for new developers. Since progress on this repo is generally slow, I'd prefer to prioritize more pressing issues.

[cjdelisle]

Understood, thanks. I'll close this now and if anyone else has an opinion about it then they can re-open.