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
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.