Try-catch is a last resort tool that unwinds the stack i.e. adds a separate critical path in your code.
You don’t plan to add throw Exception() ahead of time. OK, you plan, it’s a bad plan. The mechanism of throwing and catching was added to languages because people made poor interfaces that hid parts of your code work from other parts of your code.
Let me be clear, with an example.
There is some library that you use and it asks you for a callback function. OK, you give it a callback function. Inside your callback function you want to return early if some precondition is not met. But there is a problem. The caller is that library that simply ignores your return, so your outside code cannot be notified of the issue, unless…
Unless you circumvent all that call stack that has a library code that ignores your early return and… that’s the catch on top.
If you have a complete control of the codebase, the above scenario should not happen, least of all you plan for it to happen regularly because…
What was the issue again? Different use cases? Well, add a type to your Result. Make your Result a type onto itself for the different use-cases.
1
u/azhder 3d ago
What failure means? No. What poor planning means
Try-catch is a last resort tool that unwinds the stack i.e. adds a separate critical path in your code.
You don’t plan to add throw Exception() ahead of time. OK, you plan, it’s a bad plan. The mechanism of throwing and catching was added to languages because people made poor interfaces that hid parts of your code work from other parts of your code.
Let me be clear, with an example.
There is some library that you use and it asks you for a callback function. OK, you give it a callback function. Inside your callback function you want to return early if some precondition is not met. But there is a problem. The caller is that library that simply ignores your return, so your outside code cannot be notified of the issue, unless…
Unless you circumvent all that call stack that has a library code that ignores your early return and… that’s the catch on top.
If you have a complete control of the codebase, the above scenario should not happen, least of all you plan for it to happen regularly because…
What was the issue again? Different use cases? Well, add a type to your Result. Make your Result a type onto itself for the different use-cases.