stevo_ wrote:Yes well you are throwing the expection again however.. the last time I checked, that started a new exception, complete with a stack trace from the point of its throw..
I could be wrong as I've never bothered to recheck my teachings of the past..
But you want to be:
throw ex; ing
I'd also like to point out you've turned a discussion about the best way to WRITE catching mutliple exception types.. into a debate about how to handle exceptions..
Your arguments also seem to be against the 'norm' rules of exception catching..
I'd perhaps employ a similar idea to you during very early testing.. but I would find it very hard to program production code that is to counter-act a bug somewhere else..
I know it has to happen in some cases, but only when you understand why the bug occurs and how why it is worth counter-acting vs repairing.. even then.. ugh, I'd go home feeling dirty..
I either slept through class, forgot, or never learned that you could throw the received exception without 're-throwing' it.
I shall be immediately fixing this specific code tomorrow
I'm interested, though, in how people would handle a situation where the function calls are prone to failures that are outside of your control and, at times, retryable.
In the case of drivers or other external systems, the goal would be to recover from as many errors as possible and supply the expected result to the caller if at all possible. It seems, though, that some of you feel that the exception should just happen. Am I missing something?