Re: Exception handling Organization: unknown
On Sep 30, 6:56 am, Goran <goran.pu...@gmail.com> wrote:
On Sep 30, 2:45 am, Zeljko Vrba <mordor.nos...@fly.srk.fer.hr> wrote:
But that's just the point and my greatest annoyance with Java API - most
expected situations (file not found, error while converting int to string,
etc.) have been converted to exceptions. Thus, a simple, readable, short
idiom like
if(!(f = fopen(...))) ...
suddenly becomes
try {
f = WhateverJavaAPI(...);
} catch(IOException e) {
...
}
I have to repeat what I said before: you seem to be misunderstanding
most basic reason d'?tre for excaptions. (Also: let's not discuss
Java's __checked__ exceptions ;-)). Your code is is much more likely
to be:
try
{
f = WhateverJavaAPI(...);
work with f (several operations, all of whom might fail)}
catch(const file_error& e)
{
crap!
}
Compare to error-return:
if(!(f = fopen(...))) crap!
if (!read(f...)) crap!
if (!read(f...))crap!
Funny thing about that.
My most recent experience with exceptions was
with an API which used exceptions for error
reporting.
My code ended up being in the form:
try { call_1(...); }
catch ( Except & err )
{ log( "call_1 failed (err %d) %s ... ", ... ); return }
...
try { call_2( ... ); }
catch ( Except & err )
{ log( "call_2 failed (err %d) %s ... ", ... ); return }
(Type and function names changed to protect the guilty.)
That's because the information I want to log depends upon
which call threw the exception, and the error object doesn't
say which call it was.
It would have been easier with error returns.
+ + +
There are really three situations to be considered
when talking about how to "use" exceptions:
1. Where you are writing both the "throw"
and "catch" code.
2. Where you are writing the "throw" statements,
and some other poor fool (in a different company,
perhaps) has to write the code to catch them.
3. Where you have to use some library which throws
exceptions.
Situation #1 is the easiest to argue about, because
you can always change what, when, and how is thrown
and what, when, and how it's caught.
Situation #2 is the hardest -- if you have any empathy
for the poor guy/gal who's going to use your code --
because you don't know the requirements of the code
that calls your code (if you think you _do_, then
you're a fool.) My advice is to offer a range of
options -- e.g., if you want to use exceptions,
offer a no-throw option, and maybe a call-back
and/or error return.
Situation #3 doesn't admit a lot of advice -- you
play the hand you are dealt, for better or worse.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]