Skip to content

Add "Aborted" servicerror #223

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Jun 23, 2025
Merged

Add "Aborted" servicerror #223

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
49 changes: 49 additions & 0 deletions serviceerror/aborted.go
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,49 @@
package serviceerror

import (
"fmt"

"google.golang.org/grpc/codes"
"google.golang.org/grpc/status"
)

type (
// Aborted represents an aborted error.
Aborted struct {
Message string
st *status.Status
}
)

// NewAborted returns new Aborted error.
func NewAborted(message string) error {
return &Aborted{
Message: message,
}
}

// NewAbortedf returns new Aborted error with formatted message.
func NewAbortedf(format string, args ...any) error {
return &Aborted{
Message: fmt.Sprintf(format, args...),
}
}

// Error returns string message.
func (e *Aborted) Error() string {
return e.Message
}

func (e *Aborted) Status() *status.Status {
if e.st != nil {
return e.st
}
return status.New(codes.Aborted, e.Message)
}

func newAborted(st *status.Status) error {
return &Aborted{
Message: st.Message(),
st: st,
}
}
2 changes: 1 addition & 1 deletion serviceerror/convert.go
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -94,7 +94,7 @@ func FromStatus(st *status.Status) error {
case *failure.MultiOperationExecutionAborted:
return newMultiOperationAborted(st)
default:
// fall through to st.Err()
return newAborted(st)
Copy link
Contributor

@ychebotarev ychebotarev Jun 20, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not an issue.
It looks like the only different between those errors (like return newUnavailable(st)) is the name of the structure, and the rest is the same.
Any specific reason we choose this approach instead of "newErrorWithCode" or something like that, that looks like

ErrorWithCode struct {
		Message string
                 Code  codes.Code
		st      *status.Status
	}

and then other "concrete" errors inherits from it? This way we may avoid reflection, and reduce number of error types.

Copy link
Member

@cretz cretz Jun 23, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

and then other "concrete" errors inherits from it? This way we may avoid reflection, and reduce number of error types.

Go doesn't have inheritance, and if embedding this like type Aborted struct { ErrorWithCode } you aren't reducing the number of error types, and not sure what is meant by reflection here. The duplication here is fairly normal in these cases.

Copy link
Member

@cretz cretz Jun 23, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am (only slightly) concerned this may be technically incompatible behavior changing an error type that users may be using. Can we make sure that this is clearly called out in the release notes of the next release of this repo?

Copy link
Contributor Author

@stephanos stephanos Jun 23, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right; I also thought about that for a bit.

From what I understand, the purpose of FromStatus is to convert status.Status to a particular type of service error; or fallback to status.Error if there isn't one available.

An incompatibility issue would occur if a user
(1) relied on the error message details (.Error()) or
(2) tried to cast the result to a status.Error

Both seem unlikely, but definitely technically possible.

👍 I can add a warning to the release notes.

Copy link
Member

@cretz cretz Jun 23, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about out of range and unauthenticated? Should we do those now too or wait?

Copy link
Contributor Author

@stephanos stephanos Jun 23, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good question. I'm not sure tbh. Doing it now batches the "breaking" changes; but we might also never change this.

Generally, I understand this method to act as "try to parse this status to a typed error so I can extract error details". If the status cannot be converted, I wouldn't expect users to use/expect the status.Error since it doesn't add anything over status.Status. But they still might ...

}
case codes.Internal:
switch errDetails := errDetails.(type) {
Expand Down