Skip to content

Firebase – How to extend FirebaseError?

I am implementing a cloud function for signing up with unique username and password.

In order to throw exceptions, I was previously doing the following:


if (!validateUsername(username)) {
  throw new functions.https.HttpsError(
    "Invalid username.",
      status: "error",
      code: "auth/invalid-username",
      message: "Username must be between 3 and 30 characters, including numbers, letters, hyphens, periods, or underscores.",


try {
  await validateSignUpData(
} catch(err) {
    if (err instanceof functions.https.HttpsError) {
      throw err;

    // An unknown error has occurred

    throw new functions.https.HttpsError(
      "Unexpected error.",
        status: "error",
        code: err.code ?? "unknown",
        message: err.message ?? "The registration request could not be processed. Please, try again later."

But, I don’t really like this way of throwing the exceptions in the signUpValidation module… it makes more sense to me to throw “AuthErrors” instead of “HttpsErrors”.

So, as it seems not possible to extend the default Firebase Errors, I have decided to create my own util/authErrors module:

class AuthError extends Error {
  constructor(code, message) {
    this.code = code; = "AuthError";

const authErrors = Object.freeze({
  usernameAlreadyExists(message = "The username is already in use by an existing account") {
    return new AuthError('auth/email-already-exists', message);

   ... more errors

module.exports = authErrors;

as you can see, I have created my custom Error and some factory functions for every error type. Then, in my signUpValidation.js, I just do:

if (!(await isUsernameUnique(username))) {
  throw authErrors.usernameAlreadyExists();

Is it possible to extend a FirebaseError? If not, why?

Is it considered a bad practice to work this way in order to throw custom exceptions in Cloud Functions? I mean, should I just throw HttpsErrors?


Having Custom Error Type is useful if you are going to treat it differently. For example if you have a try/catch block and want to have a different logic for your custom error. but here you are passing error to client which has no idea of either Firebase HttpsError or your custom AuthError. because at the end your object will be serialized to JSON and at the other end there is no class to convert it back to HttpsError or AuthError.

Also at HTTP protocol level, authentication errors are defined by HTTP status codes (e.g. 401 ,403) so they are not inherently different object types. What I’m saying is that I don’t see any advantage in having a custom AuthError class on your server side when it can not be transformed as it is to your client to be treated differently. For client the HTTP status code is the key to differentiate an Auth error from other type of errors.