The ticket at the top of Brian's queue seemed strange, but not entirely unheard of. A user had entered in a bit of data in a text box on the company's flagship internal web app, clicked Submit and - boom - immediately redirected to a 404 error page. The next ticket was for the same app, same page, same text box and data, but, to make things interesting, the user reached instead a Java exception page.
The rest of the tickets landing rapid-fire into Brian's inbox were more of the same...and using the user's input, Brian could reproduce both results at will. So. Much. Fun.
Undaunted, Brian dug into the code wondering what he might find. Was there some other process that was stomping on the application's memory? Perhaps there is a problem with the disk. (Was the server guy sick today?) The possibilities behind the root cause were nearly endless, the volume of which was filling Brian with despair, that is until he found the following.
Random r = new Random(); int flip = r.nextInt(3); if (flip % 2 == 0) { if (debuggingEnabled) { %>Redirecting...<br /><% out.flush();} // Handle redirects %><%@include file="/redirect.jsp"%><% return; } else { if (debuggingEnabled) { %>Declined<br /><% out.flush();} throw new Exception(Translate.translate(lang, "Declined.")); }
The code revealed that, upon error, users have roughly a 50/50 chance of being sent to a useless redirect page or getting an Exception thrown in their face. How could this is useful in any way? Was it some kind of sick joke!?
For an instant, Brian was tempted to flip a coin choosing to remove one error in favor of the other - OH SUCH POWER! - but in the end, he went for the more practical route. Brian applied an emergency fix to handle the user input and sent a note to his manager who was, ironically, the Machiavellian developer responsible for the code in the first place.