Fiel Wrote:Everywhere I look in Java code I always see try/catch exceptions. Don't you think this is poor programming? The programmer should be able to come up with any exception that the program might run across and program against those things happening, not to have a try/catch exception which can result in buggy, unpredictable code.
Why use a try/catch when you can use if-elseif? What's the advantage to using try/catch, and why do I see so many try/catch exceptions in Java programming?
Java has checked exceptions, which means that every method has to declare which exceptions it can possibly throw and the compiler will enforce that the list is not missing anything by seeing what exceptions methods that are called can throw and which of those are caught. This is generally regarded as a bad decision, and no other language I know of has checked exceptions, including C#, the "better Java", which made a conscious decision not to enforce what exceptions you say your method can throw (which you can and should say in a doc-comment).
Suppose your method calls a method that takes a single int as a parameter and can throw ArgumentException if the number is negative. You know that your code never passes a negative number (maybe it even passes a literal int), but Java would still force you to either catch the exception or declare that your method can throw ArgumentException (or just Exception).
I think what you're getting at is things that the programmer can check for before calling a method. When that's possible, you're right, that's preferred over blindly calling and catching an exception. But that's not always possible. For example, opening a file. Even if you check whether the file exists before trying to open it, it could get deleted between the time you check and the time you try to open it.
When used correctly, exceptions eliminate the need to check the return value of every function that can have something go wrong. Sometimes the calling function doesn't know what to do about an error and the best thing to do is to let it propagate up and let some other function decide what to do. Exceptions also free the return value of a function to be used for useful information instead of an error status or a mixture of error status and information. In C++, destructors get called automatically as the stack unwinds when an exception occurs. This allows you to free resources automatically and avoid resource leaks. Other languages accomplish the same thing with finally blocks. If you're using return codes, cleanup can get pretty ugly.
Catching an exception and not doing anything about it is often but not always bad practice. Empty catch blocks should be documented saying why you're ignoring the exception.
The exceptions that can leave a method should match its level of abstraction. For example, a method that uses a cache file internally that callers do not "know about" should not throw a FileNotFoundException.
Edit: Finally, exceptions are not always the best way to signal an error. If it's something that's somewhat expected to occur and that the caller almost certainly will check for, then using an error return value or an output parameter would be more appropriate. For example, C# has int.TryParse(string s, out int result) which should be used instead of int.Parse(string s) when parsing a string from the user.
Did I miss anything?
</wall of text>