{"id":7710,"date":"2018-07-30T14:52:00","date_gmt":"2018-07-30T17:52:00","guid":{"rendered":"http:\/\/blog.plataformatec.com.br\/?p=7710"},"modified":"2018-07-30T15:13:15","modified_gmt":"2018-07-30T18:13:15","slug":"stop-hiding-the-error-and-start-fixing-the-problem","status":"publish","type":"post","link":"http:\/\/blog.plataformatec.com.br\/2018\/07\/stop-hiding-the-error-and-start-fixing-the-problem\/","title":{"rendered":"Stop hiding the error and start fixing the problem"},"content":{"rendered":"

I’ve been working on Plataformatec for 5 years and one common mistake that I see developers making is hiding the error, instead of fixing the problem. This kind of behaviour can turn your product full of problems quickly by having a codebase with unnecessary defensive programming. Let’s explore that by taking a look at an example from the real world.<\/p>\n

In some period of time, we’re working on an address autocomplete feature using Google places. Suddenly, we receive an error report complaining about an undefined object in Javascript. Something like this:<\/p>\n

Uncaught TypeError: Cannot read property 'maps' of undefined\n<\/code><\/pre>\n

A developer looked at the stacktrace, then, found the problematic line. The line was something like this:<\/p>\n

const autocomplete = new google.maps.places.Autocomplete(input, options);\n<\/code><\/pre>\n

After a moment, the developer opened a Pull Request like this:<\/p>\n

\/\/ Sometimes google is undefined\nif (google) {\nconst autocomplete = new google.maps.places.Autocomplete(input, options);\n}\n<\/code><\/pre>\n

Can you say if it’s a good solution? I can say it’s an answer. Sometimes this kind of code can be a solution. However, when I see a solution like this, too easy, it sets my spidey sense off. Let’s see why it’s not good.<\/p>\n

That code initializes the Autocomplete widget. It means, when google<\/code> is undefined, the address suggestion is not working. The if<\/code> might prevent an error report, but it won’t fix the problem. This version now is worse than the previous one. Why? Now, users still can’t have the address suggestion and the team will not be aware of the problem. The code is hiding the error, not fixing the users’ problem.<\/p>\n

You might think it was a junior mistake, but I can tell you, I could see many developers with many years of experience doing that. Everybody can make a mistake, that\u2019s why we have a process of reviewing other people\u2019s code to prevent errors like this.<\/p>\n

A bad context can make a good professional produce poor results. If the leader presses the team to make the errors reports go down fast, mistakes like that become more common. People start finding the easiest way of stopping that error of being reported.<\/p>\n

\n

\u201cPeople with targets [\u2026] will probably meet the targets – even if they have to destroy the enterprise to do it.\u201d \u2013 Deming pic.twitter.com\/EJZLIZ50zT<\/a><\/p>\n

\u2014 Lindsay Holmwood \ud83d\udda4\ud83e\udde1\u2764 (@auxesis) February 5, 2017<\/a><\/p><\/blockquote>\n