- In a perfect world, yes you can handle all cases. The world is not perfect.
I completely agree the world is not perfect. We are however working within the world of computers. Nothing happens unless you tell it to or by your inaction cause it happen. We are after all at the most basic level working with a bunch of 0's and 1's.
- but sometimes stuff happens that you cannot predict or is so far on the edge that it is only goinng to happen very very seldom. like a stack over/under flow error, out of memory error and a few others that really the only thing you can do is terminate.
While I agree there is sometimes nothing can be done, this is a rare not common occurrence. Memory overflows boil down to a bad program design. Opening to many resources without cleaning things up yourself. Stack overflows occur either due to recursion or too many large objects being passed into methods. A redesign to pass by reference might be in order.
- or what happens if you are logging errors and writing them to a text or xml file and the file IO code gets a disk error?
You are correct. How do you handle errors in an error handler? Again, try to handle them but some are "fatal". Your code should however document that point in your code and provide a message to the user. If your program is a service of course then you can't do this as no UI exists. Again, this is a question of design. The failures within an error handler should be rare. If they are common, again you have a design issue.
- what does the word "Exception" mean ?
Technically any deviation from the expected is an exception. We are after all doing "complete" validation of all input right?? :->
- and
if it's not then it is a "predictable condition" and that in of it's
self means we should write normal code to test for that condition and
not let it get into a Catch () {} block.
I would argue that try/catch block should still be used. Yes standard things should be handled in code. Providing a interactive user with a message "you may not enter zero for the monthly balance" is better than division by zero errors. In all cases you should still document the failure. If you should a message to someone is your choice.
but it's easy to just wrap stuff in try/catch blocks and try to handle it ...
but that's *NOT* really what they are meant for.
- harder work for us to avoid the catch block trap, but better quality if we do.
I completely agree. We are after all only human. I view try/catches as a way to fine tune your programmed error processing over time. You can after all log variable states within your capture blocks.