When it comes to real-time code, problems often arise. We, as developers, have to manage these types of errors in the best possible way to achieve these goals:
You know what the problem is and where the code originated
End-user don't have to see the error
Messages contain useful information
Being in production does not imply any error reporting by console.
I suggest making a reusable function to deal with messages in code.
Checklist
[ ] When in production no console messages are shown (maybe adding a guard over process.env.NODE_ENV == 'production').
[ ] When in production a new entry in the Error DB table should be included.
[ ] Console.log can be seen in testing and dev environments.
[ ] Logs can be of type server or logic, and render, client (default). Uses the function sendError created in [THIS PR].(https://github.com/Azordev/dasher-user/pull/77). Logic being bad code, render being something that breaker app visually , and server something related to client/server communication.
[ ] It has parameters error, location and type.
[ ] returns true if the request succeeded, forcibly console.log if failed and returns false.
When it comes to real-time code, problems often arise. We, as developers, have to manage these types of errors in the best possible way to achieve these goals:
I suggest making a reusable function to deal with messages in code.
Checklist
process.env.NODE_ENV == 'production'
).logic
, andrender
,client
(default). Uses the functionsendError
created in [THIS PR].(https://github.com/Azordev/dasher-user/pull/77). Logic being bad code, render being something that breaker app visually , and server something related to client/server communication.error
,location
andtype
.