I couldn't find any situation where an exception is not handled; so nothing to do for this task.

However, whilst looking through the code, I created this overview about the situations that result in more generic error responses and some follow up questions.

1. Errors when validating a patch that result in a generic invalid-patch error response:
   • Patch Operation isn't a JSON object
2. I couldn't find any situation that would result in a generic cannot-apply-patch error response.
3. All errors when deserializing a patched statement result in a generic patched-statement-invalid error response due to the decision to not handle them in this story.
4. The JsonDiffStatementPatcher validates a patched Statement with the SnakValidator. The SnakValidator can return an error Result with an Error that has a code. A bad-value-type code results in a patched-statement-value-type-mismatch error response. All other codes result in a generic patched-statement-invalid error response, including:
   • no-such-property - when no Property with the given Id can be found
   • bad-data-type - when the datatype is not known
   • bad-value - when the datavalue could not be deserialized
   • all errors returned from a ValueValidator (e.g. a url-scheme-missing from a UrlValidator)

It would be good to be able to provide more specific errors for the Statement/Snak validation errors listed in #4. However, similar to the decision made around #3, these aren't really patching related errors and so I don't think they need to be handled as part of this story.

That does prompt me to question whether the patched-statement-value-type-mismatch error response is really a patching error? Also, should these validation error codes be included in our error responses (either as the error code or in the context) given that anyone can add a ValueValidator (via a Wikibase extension) that creates an Error with a different code? Something to think about once T321459: 🌯️ Adjust statement data structure in Wikibase REST API responses and requests is done.

We might want to consider logging/monitoring/tracking when these more generic error responses are used in order to help inform us if there are error situations we haven't foreseen that would be beneficial to handle more specifically.

Thanks @Ollie.Shotton_WMDE for investigating!

I couldn't find any situation that would result in a generic cannot-apply-patch error response.

This feels a bit odd, but IMO it's ok because it means we can upgrade to new versions of the library more confidently. Any new kinds of exceptions thrown when the patch is applied should then get caught there.

It would be good to be able to provide more specific errors for the Statement/Snak validation errors listed in #4.

+1 would be nice at some point, and as you said they will likely resurface on their own.

That does prompt me to question whether the patched-statement-value-type-mismatch error response is really a patching error?

What separates this case from the ones mentioned in point #3 is that it doesn't result in (a lot of) additional effort whether we work on it now or later. #3 was about error handling which would need to be almost completely reworked with the new statement format, so it made sense to cut those out here.

Moving to product verification in case @WMDE-leszek also wants to response to one of the points.

I agree with @Jakob_WMDE 's points.
Further invalid patch errors could be added later but we're good for now I'd think. Let's see what error situations clients face commonly etc.