operationreport.Report and error wrapping

[Aenimus]

Problem

Errors are passed "up" several levels, concatenating a string as it goes.
This means we loose the ability to unwrap the error properly.

Potential solution

Currently, operationreport.go has this structure:

type Report struct {
    InternalErrors []error
    ExternalErrors []ExternalError
}

I propose this sort of change:

Note that this is just a rough proposal. I think we would also want a OperationErrors type that is an alias for []OperationError, because we can return more than one error at a time. We can then add new prefixes to display in front of the slice of errors as the errors move "up". Of course, I'll need to think about how that's handled.

type Report struct {
     OperationErrors []OperationError
}

type OperationError struct {
    ErrorType ErrorType
    Message string
    Locations []graphqlerrors.Location
    Path ast.Path
}

func (r *Report) AddOperationError(err OperationError) {
    r.OperationErrors = append(r.OperationErrors, err)
}

func (o *OperationError) Error() string {
    return fmt.Sprintf("%s: %s, %+v, %v", o.ErrorType, o.Message, o.Locations, o.Path)
}

The OperationError would be constructed such that an external error would have an ErrorType of external, and an internal error would have an ErrorType of internal. Internal errors would have blank locations and paths.

The Error() method would concatenate everything together as before, and can be called where necessary. However, we would also have access to all parts of the error if we pass the OperationError instead of a concatenated string.

[jensneuse]

Sounds legit to me. One question, would it be implemented with a method to "print" the report as "public facing", with public errors only, and then with another option to also print internal errors or how would that work? I'd just like to avoid exposing internal errors.

[Aenimus]

We're going with a different direction that requires no changes to report, including its Error() method.

There'll be a PoC soonish.

[Aenimus]

Regarding internal errors, the Report already contains all the InternalErrors, so they've always been accessible. We're only going to be displaying errors that were always displayed (external errors).