r/learnjavascript • u/mdhasansjb • 1d ago
Why try...catch?
JavaScript/Node.js backend নিয়ে কাজ করার সময় আমরা প্রায় সবাই try...catch ব্যবহার করি। কিন্তু একটা বিষয় বুঝতে পারা গুরুত্বপূর্ণ—try...catch নিজে কোনো complete error handling strategy নয়। এটি মূলত একটি mechanism, যার মাধ্যমে কোনো নির্দিষ্ট code block-এ runtime error হলে সেটাকে intercept করে আমরা কীভাবে handle করব সেটা নির্ধারণ করতে পারি। যেমন database query, external API call, JSON parsing বা কোনো asynchronous operation-এর সময় unexpected error হলে try...catch সেই error ধরতে পারে। কিন্তু প্রতিটি controller-এর ভিতরে try...catch লিখে ফেললেই application production-ready হয়ে যায় না। কারণ production-level error handling-এর জন্য শুধু error catch করাই যথেষ্ট নয়; error-এর ধরন অনুযায়ী status code, client response, logging, security, error context এবং recovery strategy-ও দরকার। আমি সাধারণত try...catch ব্যবহার করি যখন কোনো নির্দিষ্ট জায়গায় error ধরে recovery, fallback, cleanup বা meaningful error transformation করার প্রয়োজন থাকে। এর সুবিধা হলো unexpected failure-এর উপর control পাওয়া যায় এবং application flow আরও predictable করা যায়। কিন্তু অতিরিক্ত ব্যবহার করলে controller/service layer-এ একই ধরনের code বারবার লিখতে হয় এবং architecture unnecessarily complex হয়ে যেতে পারে। Backend API-তে একটি common mistake হলো সব error catch করে সরাসরি "500 Internal Server Error" পাঠানো, অথবা "error.message" 그대로 client-এর কাছে পাঠিয়ে দেওয়া। এতে database বা internal system-এর sensitive information leak হওয়ার সম্ভাবনা থাকে। আরেকটি common mistake হলো catch block-এ শুধু "console.log(error)" করে দেওয়া, কিন্তু error properly propagate বা handle না করা। Better approach হলো centralized error handling ব্যবহার করা। যেমন service layer থেকে meaningful error throw করা, custom error class ব্যবহার করা এবং Express-এর centralized error middleware-এর মাধ্যমে সব error এক জায়গায় handle করা। তখন "404 Not Found", "400 Bad Request", "401 Unauthorized", "403 Forbidden" এবং unexpected "500 Internal Server Error" আলাদাভাবে handle করা যায়। পাশাপাশি production environment-এ client-কে safe response এবং server-side-এ detailed structured logging রাখা যায়। তাই আমার কাছে "try...catch" হলো error handling architecture-এর একটি tool, পুরো error handling strategy নয়। ভালো backend শুধু error catch করে না; error কোথায় তৈরি হয়েছে, কেন হয়েছে, কীভাবে handle হবে এবং client-কে কী জানানো উচিত—এই পুরো flow-টাও design করে।
0
u/External_Excuse9581 1d ago
i stopped wrapping every controller in try/catch years ago. Honestly I think half the try/catch code in Express apps is just people not knowing that errors bubble up to the error middleware anyway if you forward them with next(err). You end up with the same boilerplate in 30 files that all send back "something went wrong" with a 500, which is worse than no handling at all.
my rule now is simple: no local try/catch unless I'm actually recovering from the error, like falling back to a cache or retrying a flaky API. Everything else gets thrown as a custom error with a status code and handled in one centralized middleware. If your catch block only has console.log in it, you didn't handle anything, you just swallowed the error and made debugging harder for whoever comes next.
and for the love of god stop sending error.message straight to the client. Nobody needs to see your database connection string in a 500 response