Error handling in server auctions
Unanswered
Great Skua posted this in #help-forum
Great SkuaOP
Hello
I learn to become fs webdev.
I learn error handling right now.
Ignore that I don't return errorMessage for now, am I doing good with the console.logs or its too much info? this is example for one function
Also, what tips can you give me from the existing code?
I learn to become fs webdev.
I learn error handling right now.
Ignore that I don't return errorMessage for now, am I doing good with the console.logs or its too much info? this is example for one function
Also, what tips can you give me from the existing code?
export async function signIn(formData: FormData) {
try {
console.log("Attempting to sign in a user via form");
const { user } = await auth.api.signInEmail({
body: {
email: formData.get("email") as string,
password: formData.get("password") as string
},
});
if (!user) throw new Error("Could not sign in the new user via form");
console.log("Success!");
} catch (error) {
console.error("Error: Could not sign in the user", error);
}
redirect("/");
}7 Replies
Transvaal lion
1. Use validation like empty string check before even hitting the auth api. this reduces api cost.
2. Better use type guard than type casting
3. extract email and password outside try/catch
4. you have repeated part of error message "Could not sign...". you should use more specific error message if no user.
5. redirect is happening no matter what login is success or fail. to prevent this, you can either throw again from catch block, or just return from there.
2. Better use type guard than type casting
3. extract email and password outside try/catch
4. you have repeated part of error message "Could not sign...". you should use more specific error message if no user.
5. redirect is happening no matter what login is success or fail. to prevent this, you can either throw again from catch block, or just return from there.
also, for production, this amount of console log is not needed. Actually, we even enable the eslint rule to restrict the console.log in the repo. console error is fine and needed.
hope it helps
Great SkuaOP
I will finish another subject then I will come to this reply, read and answer to you.
Thank you ❤️
Thank you ❤️
@Transvaal lion 1. Use validation like empty string check before even hitting the auth api. this reduces api cost.
2. Better use type guard than type casting
3. extract email and password outside try/catch
4. you have repeated part of error message "Could not sign...". you should use more specific error message if no user.
5. redirect is happening no matter what login is success or fail. to prevent this, you can either throw again from catch block, or just return from there.
Great SkuaOP
Hi man, I'm sorry for the late reply.
About 2 - Can you tell me why its better? In nextjs official docs, they do "as string" all the time
I also started using Zod btw
About 2 - Can you tell me why its better? In nextjs official docs, they do "as string" all the time
I also started using Zod btw
Transvaal lion
If you have complete control on type of data, then type casting is perfectly fine. But in your case, the user might send File or say null which may create problem. This scenario is far edge case. If you are using zod, then you are good to go. This is one of the reason Zod exists.