If you've used Windows in the last decade, you will most likely remember this error:
Not to pinpoint Microsoft's Operating System specifically, but this happens a lot of time and for us users - leaving us confused.
Application / API Development
Similarly, when developing software and using APIs, my colleagues and myself do not often plan for errors and simply return general values such as true or false. As a previous frontend developer, in case of errors with the APIs I worked with, I often had to check in the backend codes to understand what the source of the problem.
Why is this important?
After deploying our latest work on a demo server, on launching the application, a 500 Server Error welcomes us. A front end colleague and myself try to debug it as the system works on our local systems. Turns out, after a few hustle, we've missed a configuration option. Once added, the error disappears and the application works as expected.
I immediately seize this opportunity to add a condition verifying if the configuration exists; otherwise to throw a descriptive error: "missing this variable in the configuration file".
I believe writing down descriptive errors is important particularly when starting new project. Our priorities are mostly to:
- save time and focus on the most important features
- code a Minimum Viable Project (MVP) with least effort and time
You might consider checking each and every configuration as paranoid, with too much of hassle and time consuming. Yet, the beginning of a project is the ideal time as it's still easy to add these checks for bugs that will probably happen anyway. You therefore on the longer run, save plenty of time and mental energy while avoiding frustration caused by spinning around whenever encountering errors.
Sometimes even if I write the codes myself, after a few days when an error arises, I struggle to understand what is happening, especially without a try catch statement or a generic one on encompassing the whole function.
During my study at University, I remember learning Java programming in which the author always used try catch statements in his examples.
I think that's too much of a hard work but apparently not knowing what is happening behind is worst especially when working on codes you've written several months ago.
I also like to use the chalk library to make the logs more colourful and therefore more interesting to use. I usually add logs of different colours namely: magenta, cyan, yellow and green for illustrating parameters or Sequelize Objects.
In addition, for better consistency and more options, you can use dedicated libraries such as Winston, log4js and bunyan. I think bunyan is an excellent solution that I consider using for next projects.
Plus if you don't want the logs on the same server for security reasons, you can use cloud alternatives such as bugsnap which will store your logs somewhere else - that you can access to at a snap whenever needed.