Closed priyanshu20 closed 3 years ago
@ArunTeltia please review
Indentation please and instead of consoling those error can we just work on what king of error we can get from it even the comment about the type of error can help, This looks good to me for right now but this also needs to be addressed, for now lets focus on the indentation of the code. @priyanshu20 please have a look
@ArunTeltia
@singhayushh I did that in the first commit but realized that in the existing codebase almost everywhere errors are logged , rather than rendered. So I removed the res.render
@singhayushh It will not give the error page it will just send back the call with nothing inside it and the frontend that would been expecting some data will not recieve any data and the data will not get render this is better then breaking the server and restarting it after breaking it As restart of the server consume resources(thinking of an AWS instance or GCP instance ) Anyway that will be the great start on knowing how many types of error one can get and then if somehow we get those errors how can we make our frontend behave
@ArunTeltia
- for the indentation I made a commit
- for error types , I think there are a lot of error types per controller, how do I classify them ? according to me there would have to be 5-6 if blocks per controller as there are multiple errors that can occur
Lets focus on one route and work on the number of issues a route can get whether the fetch api we are using can recieve 404 error or something We want to know what error we can get from those api @priyanshu20
fixes #1
Added a try catch block for all controllers, this prevents app form crashing whenever an error occurs.