[Vertex AI] Add CustomNSError conformance to BackendError

[andrewheard]

Added CustomNSError conformance to BackendError. This improves the string returned by localizedDescription and will also improve interoperability with Crashlytics (e.g., when reporting non-fatal errors, logged errors are grouped by domain and code).

Example - calling error.localizedDescription in testGenerateContent_failure_invalidAPIKey():

• Before: The operation couldn’t be completed. (FirebaseVertexAI.BackendError error 1.)
• Now: "API key not valid. Please pass a valid API key. (com.google.firebase.vertexai.BackendError - HTTP 400 INVALID_ARGUMENT)"

#no-changelog

[ncooke3]

Nice improvement. For future consideration, do you think more of our Swift errors should conform to NSCustomError? It seems odd that there isn't a more obvious Swift type to do this. I looked at the LocalizedError protocol, but it doesn't look like an equally good fit.

[andrewheard]

Nice improvement. For future consideration, do you think more of our Swift errors should conform to NSCustomError? It seems odd that there isn't a more obvious Swift type to do this. I looked at the LocalizedError protocol, but it doesn't look like an equally good fit.

@ncooke3 That's a good question. I haven't figured out a good rule of thumb as to whether to conform to NSCustomError. In some cases like error enums the code comes from the enum case index and the domain comes from the type name (both are typically reasonable). I think Swift devs often ignore those too.

In this particular scenario, since BackendError is an internal type, I wanted to make it as easy as possible to extract the useful debugging info since it's most commonly thrown in wrapped form:

firebase-ios-sdk/FirebaseVertexAI/Sources/GenerateContentError.swift

Lines 19 to 21 in bc41b66

	public enum GenerateContentError: Error {
	/// An internal error occurred. See the underlying error for more context.
	case internalError(underlying: Error)

It's also open for debate whether to implement LocalizedError (or NSLocalizedDescriptionKey in the userInfo dictionary) in cases like this where we aren't actually providing a localized error (i.e., it's purely English). My argument here was that auto-generated message The operation couldn’t be completed. wasn't very useful, even though it would be translated. I don't think devs would want to display this error (before or after) directly in their UIs.

That's my brain dump so far but would be good to figure out a set of guidelines for the future.