Is it better to catch exceptions or avoid exceptions at any cost? [closed]

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 8 years ago.

Improve this question

What's the best practice when you're dealing with exceptions?

I usually write code to avoid exceptions at any cost, my code usually has a lot of conditions and if I'm dealing with normalized databases, I usually write a bunch of queries that double check if the values are already there.

However, I've seen code that just listens for exceptions, and if an exception occurs then it is handled appropriately.

What are the best practices in this scenario?

Is it better to avoid errors and handle them before they happen, or just catch the exception and channel it to the right place?

In terms of performance, I've seen that it's faster to catch the exceptions; especially if there's a database involved.

However, I feel that some exceptions are too general for specific scenarios and it's hard to determine why that exception occured unless you see the stack trace.

That said, unless you have a error reporting tool in place (rollbar, new relic, etc..) is especially hard to find the stack trace in the logs if you have customer facing interfaces and you receive tickets that only contain the words "500 error in X page".

If this question is too broad for stackoverflow feel free to close it

Answer 1

If there is concurrent updates happening in your database and your database access methods of checking and writing is not in one transaction you must anyway implement exception handling. So I would say that you might be better off just implementing a thorough and stable exception handling. But to answer this in general is very hard, because it always depends on the circumstances.