Monday, January 28, 2013

Exception Handling for Input Validation? Not My Cup of Tea!

We all know the importance of input validation, and we all have different views on implementation aspects: white-listing vs. black-listing, serialized vs. canonicalize, etc. etc. etc.

Lately, I was involved in a heated discussion about using Java and .NET Exception Handling mechanism to perform tasks such as input validation, as opposed to if-then-else control statement (that I was advocating for).

In theory, both mechanisms can be used to perform validation and handling of an invalid input, but here are two arguments why if-then-else control statement is a better fit:

From a conceptual stand point, exception is defined by Oracle as "an event, which occurs during the execution of a program, that disrupts the normal flow of the program's instructions" (Oracle n.d.). Does invalid user input considered as exceptional event? Hardly so as it is quite likely for the end-user to make a mistake (intentional - malicious, or unintentional) therefore the software is expected to handle it. Rico Mariani (2003) writes "If you think it will be at all normal for anyone to want to catch your exception, then probably it shouldn't be an exception at all" (Rico Mariani, 2003).

From a performance standpoint (here, I will sound like an ageing C/C++ software developer), exception handling mechanism is (really) expensive!

To examine the last statement that Java exception handling mechanism is significantly more expensive than a simple such as if-then-else flow control statement, I have created the following two Java classes:

In order to monitor the resource consumption, I have used NetBeans Profiler.

The do-while loop was designed to for the application into an infinitive loop allowing monitoring of the resources allocation over extensive period of time (generates large statistical sample).a
Initially, the code in Profile 2 was commented out and executed. The NetBeans Profiler generated the following graph:

Then, Profile 1 section was commented out and Profile 2 uncommented. The application was executed again with the following graph generated by NetBeans Profiler:

Please note the following observation:

Memory consumption of the application utilizing exceptionhandling mechanism is close to 512MB - a maximum set for the JVM, while application utilizing if-then-elsecontrol statement barely uses 5MB.

Surviving Generation, a number of instances that are alive in the heap (Jiri Sedlacek, n.d) grows linearly (to a certain point when Garbage Collector unallocates heap memory, than rises again) in application relying on exceptionhandling, while remaining flat in application relying on if-then-else control statement indicating no redundant object allocation and deallocation.

I have expected based on the conducted research that exception handling mechanism will require more resources than a simple control statement, but the results (times hundred in terms of memory consumption and linear vs. static number of objects in heap) emphasise the important of understanding the "under the hood" mechanisms employed by the software.

Moreover, the experiment demonstrates how a security mechanism (exception handling) can be transformed into a security vulnerability (i.e. Denial of Service) if not used correctly.

In a real application, a combination of both should be used to provide an adequate layer of security: if-then-else control statement to handle expected (and to a certain degree, unexpected) data while exception handling mechanism to allow the software to either recover from an unexpected error or fail gracefully.