Software Engineering Management & Warning logs vs Fatal logs

How to handle side effects

Photo by janilson furtado on Unsplash

An underrated activity in software development from my experience is logging management. I do not want to dwell on the fact that what is recorded is often written in a way not understandable, or without a fixed scheme (which helps the log collection and analysis for SaaS products through dedicated software such as Logstash); instead I would like to think about the situation in which one is in doubt if it is better to log either a WARNING message or an ERROR message or even a FATAL one.

I ‘ve never been able to have a 100% consensus on the log level for critical situations, mainly because people sometimes feel the criticality in completely different ways. But to be as concrete and objective as possible I’ll begin to quote the common standard meaning for these three log levels:

Just from the above descriptions you can see how sometimes it is hard to select one or another log level. But the situation I face most of the time is the one where your application has to start with a given input shaped in a specific (even complex) way. What should we log if the application recognizes that the input data is missing or even incorrectly modeled?

If these incorrect inputs broke the functionality of the application or even if the output produced are meaningless I would like to stop the application as soon as possible informing of the detected problems for which the abnormal behaviour has been observed. So this goes more in the approach of the FATAL management. Clearly this is a difficult road and probably the best option I would desire is to have an application designed as robust as possible to be resilient against errors and therefore able to move foreward without degradation (especially in a SaaS context), but it is not easy and not feasible everytime. Peraphs the situation can be mitigated if your application has a User Interface and you can visually notify the user that something is going wrong and you can disable the affected functionalities at the UI level. While this approach is possible, it is still not easy to follow because it requires a fairly good and modular design of your application. But what if your application does not have any UI, but only a set of APIs? I think that even in this case the approach should be robust in the sense that the API responses should contain the the error info.

Something that I totally disagree is when I hear proposals where it is claimed to go on with the application just logging WARNING or ERROR and not giving any other feedback to the user, assuming that he will be able to understand the results he is getting are corrupted and so that he will inspect the log files. This type of approach is failing for me in both the assumptions because nobody can grant the user will be capable to recognized crapped outputs, and why should we think that the log file will be read by the user? This type of approach is rooted in the assumption that you have clever users.

The key to a product’s success is its simplicity and it does not mean that it has zero complexity, but it is shaped in a way that the cognitive load of the user is minimized. The smoother and easier the user experience, the better.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Alessandro Attanasi

Engineering Manager at PTV Group for Real-Time mobility. PhD in physics with passion in Computer Science, Statistics, ML/AI. Motto: “Never stop learning”