Remove custom error types

[manish-sethi]

This commit removes the custom error types that are not used by the consumers

Type of change

• Improvement (improvement to code)

Additional details

Previously one of the custom error types NotFoundInIndexErr was used in the validation path, with this PR, it's no longer the case.

[ale-linux]

Are the error strings produced now identical to those produced earlier? If not, we might be messing up with some scripting built around assumptions on error string.

[manish-sethi]

Are the error strings produced now identical to those produced earlier? If not, we might be messing up with some scripting built around assumptions on error string.

No, the error strings are enhanced for a better message than a generic message. These functions are invoked via qscc and error is reported via shim.Error (a response code and the error string). The error string is prepended with another string message, for instance this. So, the latter part of the final error string could be different for different conditions and new error conditions are also added lately. I am not sure whether we are committed to maintain the latter part of the error string throughout the code stack and is it even possible without having a test for all the error conditions and the corresponding messages. In some cases, even third party libraries error strings that we use underneath may change. Still, better to take others' views on this for a choice between not committed for this vs knowingly breaking - @sykesm, @denyeart - any opinions on this?

[denyeart]

This doesn't seem like a particularly common error message that clients would script for, therefore my opinion is that the improved error messages outweigh the backward compatibility concern in this case.

[denyeart]

Approving, but let's see if @sykesm or @ale-linux have any final comments about error message backward compatibility.

[cendhu]

IMO, for error checking at the client side, error codes might be the correct choice instead of string comparison. The client side scripting cannot rely on error string as it need not be constant across releases.

[sykesm]

Approving, but let's see if @sykesm or @ale-linux have any final comments about error message backward compatibility.

I’m fine with this.