Estoy implementando una función en la nube para registrarme con un nombre de usuario y una contraseña únicos.
Para lanzar excepciones, anteriormente estaba haciendo lo siguiente:
signUpValidation.js
if (!validateUsername(username)) { throw new functions.https.HttpsError( "invalid-argument", "Invalid username.", { status: "error", code: "auth/invalid-username", message: "Username must be between 3 and 30 characters, including numbers, letters, hyphens, periods, or underscores.", } ); }signUp.function.js
try { await validateSignUpData( username, email, password, repeatPassword, name, birthday, clientIp ); } catch(err) { if (err instanceof functions.https.HttpsError) { throw err; } // An unknown error has occurred console.error(err); throw new functions.https.HttpsError( "unknown", "Unexpected error.", { status: "error", code: err.code ?? "unknown", message: err.message ?? "The registration request could not be processed. Please, try again later." } ); }Pero, realmente no me gusta esta forma de lanzar las excepciones en el módulo signUpValidation... tiene más sentido para mí lanzar "AuthErrors" en lugar de "HttpsErrors".
Entonces, como parece que no es posible extender los errores predeterminados de Firebase, he decidido crear mi propio módulo util/authErrors :
class AuthError extends Error { constructor(code, message) { super(message); this.code = code; this.name = "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;como puede ver, he creado mi error personalizado y algunas funciones de fábrica para cada tipo de error. Luego, en mi signUpValidation.js , solo hago lo siguiente:
if (!(await isUsernameUnique(username))) { throw authErrors.usernameAlreadyExists(); }¿Es posible extender un FirebaseError? Si no, ¿por qué?
¿Se considera una mala práctica trabajar de esta manera para generar excepciones personalizadas en Cloud Functions? Quiero decir, ¿debería lanzar HttpsErrors?
Tener un tipo de error personalizado es útil si lo va a tratar de manera diferente. Por ejemplo, si tiene un bloque de prueba/captura y desea tener una lógica diferente para su error personalizado. pero aquí está pasando un error al cliente que no tiene idea de Firebase HttpsError o su AuthError personalizado. porque al final su objeto se serializará en JSON y en el otro extremo no hay ninguna clase para volver a convertirlo en HttpsError o AuthError.
También a nivel de protocolo HTTP, los errores de autenticación se definen mediante códigos de estado HTTP (p. ej., 401, 403), por lo que no son tipos de objetos inherentemente diferentes. Lo que digo es que no veo ninguna ventaja en tener una clase AuthError personalizada en su lado del servidor cuando no se puede transformar como lo es para que su cliente sea tratado de manera diferente. Para el cliente, el código de estado HTTP es la clave para diferenciar un error de autenticación de otro tipo de errores.