Try...Catch State of Mind

Parth Raghav,Startups

If-Else and Try-Catch are two primitive programming idioms. If-Else statements are used to control the flow of your program based on certain conditions. If a condition is true, a particular block of code is executed. Otherwise, a different block of code is executed. On the other hand, Try-Catch statements handle errors that occur at runtime. When a block of code is executed within a Try block, any exceptions that are thrown are caught by the corresponding Catch block. This allows programs to handle potential errors in a controlled way rather than letting themselves crash.

The philosophical difference between the two control flow constructs is best summarised by Grace Hopper’s aphorism, “It’s easier to ask forgiveness than it is to get permission.” Try-Catch statements embody the idea of quickly taking action and dealing with any consequences later. In contrast, If-Else statements require the programmer to seek permission and anticipate ALL potential errors if the program is not to crash. Although the two constructs can’t always be used interchangeably because of their different purposes, when it comes to communicating with other machines, it is trivial to note that Try-Catch statements allow for a more agile and responsive approach to programming. They allow the program to continue running even if an error or exception occurs. On the other hand, If-Else statements make the system rigid and less flexible, as they require the programmer to anticipate every potential error or exception.

Consider the following code example. The system with If…Else can break just as much due to latency issues, race conditions, logical short-circuiting (for example, when the isServerAtCapacity endpoint is unreachable when the server is at capacity), or any unexpected failures. Except now it is more complex with more API calls, ergo more compute, and added dev time, it doesn’t necessarily solve the problem of permissioning an API call, to begin with. We find that the permissions gathered were useless.

The reactive approach always wins between the preemptive and the reactive because it is easy, simple, and often the only possible way. As a programmer turned entrepreneur, I’ve come to learn the importance of this adage in the real world. Instead of seeking approval or permission for every action, it is better to take action and deal with any consequences later. The reason is twofold. Permissions are hard to get. Consequences are hard to predict.

When disruptive ideas are born, technological scaffolding is present, but the moral/legal framework is often stale or absent. Uber is a good example. When it was first founded, ride-sharing was largely unregulated and existed in a gray area of the law. Instead of seeking permission and approval from local governments, Uber launched its service and began operating.

This bold and risky move allowed Uber to grow quickly and establish itself as a leader in the ride-sharing industry. However, it also led to significant backlash and legal challenges from local governments and taxi companies. Despite these challenges, Uber continued to operate, and eventually, many local governments and regulators began to adapt their laws and regulations to accommodate the rise of ride-sharing.

When Facebook was founded in 2004, online social networking was still relatively new and untested. The technological infrastructure and tools were in place to support the growth of Facebook, such as the internet and later mobile devices. However, the legal framework surrounding online social networking was not well-developed. In 1995, the Communications Decency Act (opens in a new tab) was passed, which protected “interactive computer service providers" from liability for user-generated content. The law was designed to support Web Hosting Services and ISPs, not to deal with large-scale social platforms and their specific challenges in mind. As a result, Facebook and other social media companies navigated the legal landscape on a per-need basis.

Facebook in 2004 could not have predicted the issues of widespread misinformation and user privacy, much less the lawmakers in 1995. Asking for permission would have been pointless because what exactly are the authorities granting permissions for? Preemptively making laws, on the other hand, could stifle innovation and progress. If Facebook, with all its faults, wasn’t introduced to the free market, just how would we know how such a platform can revolutionize communication? It would be missed opportunity for the competitors to evolve the product out of its drawbacks.

With the Try…Catch State of Mind, I’m not advocating for recklessness in the name of “Move Fast, Break Things.” Uber and Facebook are good examples of companies that didn’t seek permission to disrupt. It’s interesting to note in a free market, Luddites often offload all the blame onto the product builders for the consequences of their products. Builders could only catch so many legal exceptions as the lawmakers would throw at them. If the speed of law doesn’t match the speed of disruption, is it entirely the fault of the disruptors? I figure not.

My job as a builder is to build. I want to foresee all the problems that will arise with the systems I make, but it’s hard, if not impossible, without the Time Cloth (opens in a new tab). I speak for most makers when I say we’d like to usher in a utopian world just as much as anyone else does. So obligatory as it is for the builders to Try, it is equally essential for the rest to throw exceptions we can Catch. However, to stop Trying is not the solution.