Declare errors as classes rather than interfaces

[j1mbl3s]

I would like to be able to use the React Native Firebase error types to switch between different error handling in my TypeScript code.

Currently, the error types in the RNF project are declared as interfaces. As such, I cannot use the instanceof operator to switch between handling because interfaces are only useful to the TypeScript compiler and are not transpiled to JavaScript for use by instanceof, nor can I use the notion of typed systems as intended to definitively look up the properties of an error.

For my use case, I would specifically like to know the error's code field value. I can, of course, do something like:

try {
  // perform some RNF method, potentially wrapped in a method that can throw non-RNF errors
} catch (e) {
  if (e.code) {
    // use the code for handling
    // for example:
    switch (e.code) {
      // ...
    }
  }
  // potentially some other handling
}

However, I feel that this sidesteps typed systems entirely.

I think it would make for cleaner code to be able to handle it like:

try {
  // perform some RNF method, potentially wrapped in a method that can throw non-RNF errors
} catch (e) {
  if (e instanceof ReactNativeFirebase.NativeFirebaseError) {
    // now we, and the compiler, can have more certainty of the fields on e through type casting
    // for example:
    switch ((<ReactNativeFirebase.NativeFirebaseError>e).code) {
      // ...
    }
  }
  // potentially some other handling
}

The code might be a bit more obtuse, but it makes use of the typed system more elegantly. Additionally, it can still be handled by the first example, given that e is of any type when caught and could potentially have a code field.

I think the only downside is that it would use slightly more memory given that the errors would have to be instances of ReactNativeFirebase.NativeFirebaseError extending Error, rather than just instances of Error with additional fields.

Aside

On a similar note about RNF errors, I do wonder why ReactNativeFirebase.NativeFirebaseError declares a readonly message: string field when it extends Error which already has a message: string field. Though not specifically readonly, if a developer is changing an Error's message in their code then why stop them?

[j1mbl3s]

This is an idea for a quality of life improvement. It doesn't really add anything to functionality or fix anything that is broken. Just looking for opinions on the matter.

[mikehardy]

It's an interesting point actually, and I'm sympathetic to your stance, we are pursuing a typescript conversion right now #4999 and I wonder what @Ehesp and @dackers86 think about it since they have been most active there? For what it's worth, I prefer strong types I can use in all places myself, so I'd be +1 unless those two have a good reason why not...

[Ehesp]

I'm not opposed to this idea, it's more we tend to take the lead from the Firebase JavaScript API when making these sort of decisions. I'm curious as to whether this would work for for the best of both worlds. In JS I'd like to keep it so the user can just grab error.code and everything works as normal, but for TypeScript users this sort of check is usually much better.

[macksal]

I was about to open another discussion/issue for this. I think it can be done as-is by just exporting the NativeFirebaseError class (right now it's in the internal module).

The only implication is that this class becomes part of the public interface and errors would need to continue to descend from it in the future. To me, it seems worth it - checking things like "code" in error is a bit hacky. The typescript DX is much better with a known base class to compare against.

[Dhanush-Ma]

Created an util function hope it helps

import { ReactNativeFirebase } from "@react-native-firebase/app";

/**
 * Type guard to check if the error is a NativeFirebaseError
 * @param error - The error object to check
 * @returns {boolean} - True if the error is a NativeFirebaseError
 */
export function isNativeFirebaseError(
  error: any
): error is ReactNativeFirebase.NativeFirebaseError {
  return error && error.code && error.message;
}