John Dryden wrote:I wonder who has ever battled choosing whether to use exceptions in between, say, library components, or to use enum values instead .. What did you choose?
That looks very like what one does with SQLExceptions already.
John Dryden wrote:. . .
Campbell Ritchie wrote:That looks very like what one does with SQLExceptions already.
Tim Holloway wrote:The old Exception versus return code debate. It's an old one. Both sides have their pros and cons, and only an ideologue would say that there's only one solution.
Sooner or later, it's almost inevitable that you're going to wish you'd at least logged the information you discarded.
So my general rule is return codes for high performance, Exceptions where I need more internal context, and hybrid for cases where the norm is low overhead but where there can be (ahem) exceptions.
I do usually have a fault code in there as well, but I find the instanceof test to be simpler and it requires you to assume less about the internals of the Exception.
"Network not available" means no networking at all is possible.
Host Unavailable is something you could get if the host you're talking to is online, but not responding to you.
If a host is down, then it's both unavailable and there's no route to it, so take your pick.
Tim Holloway wrote:First, the "git 'r Dun" approach makes me (and many of my friends) grind their teeth.
Failing to think things through is what gets a lot of people put on call nights and weekends.
Throw away diagnostic information especially when the code is still in development and you'll see me get extremely hostile.
I have enough grief with mis-placed commas and improper capitalization without deliberate actions. This is because one thing I've learned is that for most projects I'll end up spending more days tracking down trivial errors than I will on the technically-demanding parts of the system.
Second, I can very definitely get a "no route to host" on my network when a host is unavailable and all too frequently do.
But a lot of network errors get reported in different ways depending on topology, drivers, and operating systems.
On the subject of setting multiple catch clauses for related but different exceptions, I plead personal experience. It's just generally easier. Case in point: Many things can throw an SQLException, but some of them should be intercepted immediately, and others are typically tossed uphill. You might get an end-of-data exception that would terminate a transfer loop method, for example, and the transfer would clean up and return normally, perhaps to be called again for a new transfer. Or even multiple transfers in a transfer loop that each end with end-of-data exception. But an exception due to a broken link basically ruins the whole setup, so you might as well kill it from the top down instead of futilely wasting time in intermediate code that cannot work. Value tests are fine when everything's on the same level, but not so good when there are multiple levels involved.
But as I said in the beginning, there's no one-size-fits-all solution. It's partly going to be the context you're working in and partly personal preference. There's rarely one "right" answer here. Leave that for politics and religion.
Tim Holloway wrote:Second, I can very definitely get a "no route to host" on my network when a host is unavailable and all too frequently do. It has multiple segments.