fix: don't unwrap when not found error is thrown

[Pelto]

When we have a sturdyc.Client[any] we run into errors when we have missing records.

It seems like the cache is trying to do unwrap on the values even when we have told the cache that the result isn't found. This is not an issue when we have sturdyc.Client[FancyStruct] but happens when we have any.

I believe it is since when that happens and any=interface{} causes us to unwrap a nil value and hence we return ErrInvalidType instead.

[viccon]

Hi, can you see if you still experience the wrong behavior on this branch? #40 I've made a bunch of changes to the error handling and generics there

[Pelto]

Added a unit test that does fail on the branch in the other pull request.

The problem still persists there that you enter unwrap with a nil value. Then as that is the last step it will fail as the cache is set to any. Then we fail as we end trying to do v, ok := any(nil).(any)

So similar to the other branch in some ways, but this is more due to to the fact that way Go handles generics is a bit meh :)

[viccon]

Hi, thank you so much for including a failing test - that really speeds up troubleshooting! This happens because when ErrNotFound is encountered, the cache stores the zero value of T (which, for any, is nil). Later, when we try to retrieve it, we get a cached value and don't actually use the wrapped fetch function. Instead, we return the nil value from the cache, where an unwrap is attempted, resulting in an ErrInvalidType error.

I also agree that generics in Go are a bit meh. There is currently a high cost to implementing the API the way I did, e.g removing the need for constant type assertions if you want to use the cache to store more than one type. The cache has to perform these runtime type checks which I feel should be handled at compile time in a language that supports generics.

I've cherry picked the changes into this PR: #40 which includes multiple error handling improvements