Recently, my boss told me that using try-catch statements is "garbage" and that we should avoid them in our development work. He didn't specify any programming language, so I'm confused because I thought error handling through try-catch was essential in most modern programming languages. I understand that it can be misused—like catching exceptions without any handling, or using it as a control flow method—but to completely dismiss it seems extreme. Is there a programming philosophy that supports this view? Are there better alternatives to try-catch? Has anyone else run into this "no try-catch" mentality? What are the best practices for exception handling across various languages? I want to know if there's a legitimate reasoning behind this or if I should challenge this advice.
4 Answers
I think you should definitely ask your boss to clarify what he means. Sometimes, when people criticize something like try-catch, they really mean that it's being misused rather than the concept itself being bad. It's vital for handling errors that occur outside of your control, like API failures or file-read issues. Forgetting to handle those situations properly can crash your application. It's also important to understand the context where your boss is coming from. Has he had bad experiences with it being used incorrectly? That might inform his opinion.
Agreed. It's essential to know the right use cases so you can explain its value in maintaining system stability.
I get where your boss is coming from, but it's an extreme view. The important thing is how you handle exceptions. For example, in C# and Java, using try-catch responsibly is recommended to maintain control over unexpected errors. Try-catch should be used sparingly and only for exceptions that are genuinely unexpected. Encourage your boss to explain how he'd prefer those situations to be handled instead.
Exactly! And guiding the discussion towards specific cases where he feels it fails could help clarify things.
That's the way! Keep it focused on benefits rather than blanket statements.
Your boss might be leaning towards an old-school philosophy. In the past, exceptions were slow and heavy on performance, so some developers advised against using them broadly. However, in modern programming, the consensus is to use try-catch at critical boundary points—like when calling APIs or reading files. The key guidelines are: don't use exceptions for regular control flow and don’t catch what you can’t handle. Simply saying "try-catch is garbage" is an oversimplification.
Definitely! I’ve seen this mindset before. It's often rooted in past experiences where exceptions were indeed costly.
Right! And with today's languages optimizing exception handling, dismissing it outright just isn't practical.
Usually when I hear that try-catch is garbage, it's a misunderstanding of its purpose. It's a tool, and used correctly, it can be incredibly useful for error management without cluttering the control flow. The focus should be on clear design rather than avoiding tools altogether. If your boss isn't open to understanding that, it might be worth having a deeper discussion about error handling practices in modern development.
Absolutely, I'm all for discussing the right time to use it — helping them see it's about good practices.
For sure! Engaging in a constructive dialogue could lead to a better understanding of each other's perspectives.
Exactly! Mistakes with try-catch can lead to ignoring errors entirely. It's good to engage and understand the reasoning behind his views.