You're not really addressing anything I wrote.

First of all, most people check for error

if (error) ...

and then either return from that block, which I will not do, or have the path of correct execution in an else block. So the code is mostly blocks of error handling with the path of non-error execution almost an afterthought.

I check for no-error and put the error handling in an else block. So the path of correct execution is in plain sight and easy to follow.

The problem I outlined had less to do with real exceptions, which I only catch locally, but with abuse of throw for lesser reasons. Conditions where return codes are more appropriate. And even as a way to save a little typing; What the kids are calling refactoring.

Improper and sloppy use of return codes is a completely separate problem and throw is not an answer to that. This whole approach seems to becoming more common in it; don't actually fix a problem, develop a new architecture for it that creates problems of its own. Like creating containers and Docker because new versions of frameworks break old code. That's not supposed to happen. Or burdening developers with these ceremonial methodologies instead of letting them concentrate like copmpanies used to.

The big problem with throw is that it produces code that cannot be reliably analyzed. And in garbage-collecting languages throw thwarts GC and causes memory leaks. It is enormously expensive.

I don't use throw.

Written by

American Software Developer living in Vietnam. Classical musician (guitar, woodwinds), weightlifter, multilingual, misanthrope • XY

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store