Browse Source

Downgrade non-specific errors to application-level

Usually we try to provide a helpful error message, by wrapping it in
our own `Error` struct, if something has gone wrong which can be fixed
by the intervention of the user.

If we see an error that hasn't been wrapped in this struct, as a last
resort, the HTTP API wraps it with a cover-all message. These are
translated to a "500 Internal Server Error" status.

However, since new code brings with it new errors, mostly not
accompanied by help text, which means many quite common scenarios (no
git config provided, for example) result in a cover-all error and
therefore a 500 status code. In light of this it is better to reverse
the default, and treat unwrapped errors as application-level unless
explicitly marked as internal errors.
Michael Bridgen 1 year ago
parent
commit
31e99c4836
1 changed files with 2 additions and 2 deletions
  1. 2
    2
      errors/errors.go

+ 2
- 2
errors/errors.go View File

@@ -78,9 +78,9 @@ func (e *Error) UnmarshalJSON(data []byte) error {
78 78
 
79 79
 func CoverAllError(err error) *Error {
80 80
 	return &Error{
81
-		Type: Server,
81
+		Type: User,
82 82
 		Err:  err,
83
-		Help: `Internal error: ` + err.Error() + `
83
+		Help: `Error: ` + err.Error() + `
84 84
 
85 85
 We don't have a specific help message for the error above.
86 86
 

Loading…
Cancel
Save