top of page

The advantages and disadvantages of Defensive Programming, and how Finotes finds the balance.

Updated: Feb 18, 2022


Defensive Programming

While architecting any software solution, it’s important to focus on below three principles.

  1. Incoming data is impure unless proven otherwise.

  2. All data is important unless proven otherwise.

  3. All code is insecure unless proven otherwise.

To incorporate these principles while building software applications, programmers tend to rely almost entirely on defensive programming, as if it is a divine universal solution. So wrapping entire code in multiple layers of try / catch blocks, verifying the same data at multiple points in the call flow, keeping unused data in memory because ‘all data is important’, and ignoring the 'proven otherwise' part of the principles, are common features in codebase these days. Throwing and catching Exceptions, as the name indicates, are to handle 'exceptions', and using them all over the place is an expensive bad idea.


I (almost) hate defensive programming the way it is done today.


No, I am not at all advocating not to take precautions against failure scenarios and potential security loopholes. We should. But over doing the precautionary measures do have a negative impact on the performance. Many programmers end-up doing exactly that in the name of defensive programming, and screwing up the performance as a result.


Another problem is that the defensive coding techniques end up preventing some bugs to manifest, and such bugs go unnoticed. The bugs will continue to exist, but they are not conspicuous enough. They may end up manipulating the end result, or affect the performance, but still go unnoticed. Even security bugs, though might get prevented from executing, would continue to exist as potential threats in the code. As the developer remains unware of the existence of these bugs, they go unfixed.


Of course, defensive programming has its advantages too. It helps the application much in gracefully handling unpleasant situations arising due to bugs. Also it helps in writing cleaner logging code.


So I very well understand why programmers tend to go for it.


How to make use of defensive programming while still enabling active reporting of bugs and errors? This has been one of the thought processes when we started building Finotes for detecting and reporting bugs in mobile apps. The bugs have to be reported with as much data points as possible. And there should be a call back mechanism when bugs occur so that the developer can gracefully handle the situation. The entire process should happen in a resource efficient manner utilising less of CPU and Memory. Finotes is architected based on these concepts.


The way Finotes is architected helps mobile app developers to handle the buggy situation and also get notified as and when they occur. So they get the advantage of defensive programming and also get enough information to reproduce and fix the bugs.


If you are an android app developer, and use Java or Kotlin, or if you are an iOS developer, and if you use Objective-C or Swift, do check finotes.com.

Happy bug fixing.



Blog for Mobile App Developers, Testers and App Owners

 

This blog is from Finotes Team. Finotes is a lightweight mobile APM and bug detection tool for iOS and Android apps.

In this blog we talk about iOS and Android app development technologies, languages and frameworks like Java, Kotlin, Swift, Objective-C, Dart and Flutter that are used to build mobile apps. Read articles from Finotes team about good programming and software engineering practices, testing and QA practices, performance issues and bugs, concepts and techniques. 

bottom of page