Make every not exist error unwrappable to a fs.ErrNotExist

[zeripath]

A lot of our code is repeatedly testing if individual errors are
specific types of Not Exist errors. This is repetitative and unnecesary.
Unwrap() error provides a common way of labelling an error as a
NotExist error and we can/should use this.

This PR has chosen to use the common io/fs errors e.g.
fs.ErrNotExist for our errors. This is in some ways not completely
correct as these are not filesystem errors but it seems like a
reasonable thing to do and would allow us to simplify a lot of our code
to errors.Is(err, fs.ErrNotExist) instead of
package.IsErr...NotExist(err)

I am open to suggestions to use a different base error - perhaps
models/db.ErrNotExist if that would be felt to be better.

Signed-off-by: Andrew Thornton art27@cantab.net

[zeripath]

The next step following this would be to change ServerError code to autodetect if the `Err it is passed is an fs.ErrNotExist and simply return NotFound and so on.

[zeripath]

Conflicts fixed.

[lafriks]

If the aim is to use this in ServerError why not to create interface to implement for errors that would return status code to be used for this error in response and safe error message to return in response?

something like: https://github.com/azugo/azugo/blob/main/errors.go#L16-L26

[wolfogre]

It's tiring to implement the interface by writing lots of func (err X) Unwrap() error, maybe we can provide predefined types to composite, like:

type WrapErrNotExist struct{} // TODO: need a better name

func (err WrapErrNotExist) Unwrap() error {
	return util.ErrExist
}

// ---

type ErrFooNotExist {
	WrapErrNotExist
 	// ...
}

type ErrBarNotExist {
	WrapErrNotExist
 	// ...
}

[wxiaoguang]

I agree with "this is in some ways not completely correct as these are not filesystem errors"

But :

but it seems like a
reasonable thing to do and would allow us to simplify a lot of our code
to errors.Is(err, fs.ErrNotExist) instead of
package.IsErr...NotExist(err)

Why not use our own error system, instead of using fs.ErrNotExist ?

[wxiaoguang]

@zeripath Do you think if it's better to use our own errors instead of fs errors? I agree with your thought that "This is in some ways not completely correct as these are not filesystem errors". At the moment, I can not imagine any benefit of using the fs errors, IMO using fs errors might make code a little confusing.

[zeripath]

@zeripath Do you think if it's better to use our own errors instead of fs errors? I agree with your thought that "This is in some ways not completely correct as these are not filesystem errors". At the moment, I can not imagine any benefit of using the fs errors, IMO using fs errors might make code a little confusing.

I've changed it - the main benefit of using the fs errors was that we might have been able to rely on upstream handling of these errors, but it's fine.

[zeripath]

It's tiring to implement the interface by writing lots of func (err X) Unwrap() error, maybe we can provide predefined types to composite, like:

type WrapErrNotExist struct{} // TODO: need a better name

func (err WrapErrNotExist) Unwrap() error {
	return util.ErrExist
}

// ---

type ErrFooNotExist {
	WrapErrNotExist
 	// ...
}

type ErrBarNotExist {
	WrapErrNotExist
 	// ...
}

Whilst I can see your point I'm not sure it's much better than just writing the three-line function.

What I'd like to do is get rid of most of these BlahNotExistErrs. We can create a common detailed NotExistErr if necesary:

type DetailedNotExist struct {
  Resource interface{}
}

func (d DetailedNotExist) Error() string {
   // This would use reflection... to reveal the type of the Resource and which non-empty fields are set
}

func (d DetailedNotExist) Unwrap() error {
   return NotExistErr
}

[6543]

🚀