Some Background
In OOP languages like C++/C#/Java/Python exceptions were introduced to handle the exceptional situation. Exception handl...
For further actions, you may consider blocking this person and/or reporting abuse
Exception handling is definitely not an antipattern. You are confusing weak use by beginners who lack a thorough understanding of when and how to properly use it.
Also your example where you add code to throw an exception and indicate that it doesn't appear to be a breaking change is missing something critical. Specifically, the method in that example isn't documented, so the contract for that method hasn't been specified. Throwing an exception in a method that didn't previously throw an exception changes the contract of the method, and is a breaking change. The docs for the method must fully specify its contract. So changing it to throw an exception changes the contract requiring changing the docs, revealing the breaking change.
I think you are lacking on the definition of antipattern. Antipattern is not something that you can't write good code with. Antipattern is something that makes it harder to write good code. You pointed out that often beginers makes the mistake about exceptions. But why? Because they are hard use properly. I've seen many code bases where exceptions are just ignored assuming it won't happen or handled by an earlier method.
Really? Okay I give you two option for implementation of a method. First method does exactly what it said. It doesn't require any extra documentation to explain itself. It doesn't have any side effect. The behaviour is predictable. So you can look at the definition and say okay I know exactly what it does. What a charm! Second one can throw exceptions and have side effect. Which one is better? Self explanatory predictable or one with documentation and unpredictable behaviour.
Also there were other points like data corruption, concurrency. Like I know that these can be avoided. But exceptions can create those problems. And they are not rare. You can easily find misuse of exception handling.
That's why it's rare to see exception as a feature in modern languages unless they are successor to any old language, and they have to maintain compatibility. Now it's well understood that simple input-output format functions/methods are best for any use case. Natural flow of code is important
The reason a beginner might misuse exception handling is the same for anything else they may misuse. They are new and early in learning process. Exception handling doesn't increase that. By your logic everything is an antipattern.
The alternative of returning result along with status/error code has all the same issues that you see as a disadvantage to exceptions.
No beginners do mistake about exceptions have pitfalls. As a said they have side effect whereas simple input-output mechanism always better. That's why it is adopted in new languages
No. Claiming something is "always better" than something else is rarely a true statement. Claiming that a language feature is an antipattern independent of how it's used is a misunderstanding of the notion of a pattern/antipattern. And just because something is the case in some new languages doesn't make it "better". If a language is "new" it hasn't stood the test of time yet.
Again, you are lacking on the definition of antipattern. Antipattern doesn't mean a language feature is bad independent of how it's used. It means that there is a higher possibility that it can lead to bad code. I have explained my best that why exceptions can lead to bad behavior of code
As one who teaches SE courses now and again, I absolutely do understand antipatterns. Your blanket declaration that exception handling is an antipattern is absolute nonsense. A language feature alone, without usage context, cannot be an antipattern.
There are antipatterns involving exception handling, such as the hiding exceptions antipattern, the raising unrelated/nonspecific exceptions antipattern, the catch then re-raise antipattern. There are also many exception handling related patterns.
But no, exception handling itself is neither an antipattern nor a pattern.
In your logic gotos are good to use too. Because they are also language feature. Same goes for pointer you should use that too. Don't forget goto, pointer everything provides a value. But if write C# code using that most people are gonna say avoid them. Same goes for exception they provide a value but still it's better to avoid. Not all language feature is good and shouldn't be used.
Those are also neither patterns nor antipatterns. They are just parts of languages that you can either use or not use. It is how you use them that may be a pattern or may be an antipattern or may be neither.
I'm sorry, I could not finish reading. There are so many things wrong with this I just stopped.
You are completely misunderstanding exceptions. Exceptions are the mechanism the language/application uses to inform us that something went wrong. Nobody, and I mean nobody has ever encouraged me to ignore the possibility of exceptions. The key word here is exception. It is an exceptional case, and it is therefore good and nice to be outside of the happy path.
Exceptions are also very helpful: Their main purpose is to alert, and alert they do indeed. They are alerting you to the possiblity that (taking from your example) a file is read-only or non-existing. But most importantly they are telling you that your application is not stable.
Maybe you get the idea that programmers are encouraged to ignore them because you see so many junior and mid developers adding
try..catchblocks everywhere, sometimes with an emptycatchblock. Now that's the anti-pattern. Not the exceptions themselves.I think you got my point wrong. I clearly state that exception handling is an antipattern not exception itself. Also, I mentioned that exceptions should only be used if something gone horribly wrong not just for control flow. They have all sorts of disadvantages that I pointed out. For these demerits it's rare to see exception as a feature in modern languages unless they are successor to any old language, and they have to maintain compatibility.
While I get your clarification point, I cannot shake the feeling that if I agree with you, I'll be agreeing that exception handling must go away altogether. This is why I drove myself to commenting. Saying "exception handling is an anti-pattern" is too bold of a statement.