Re: advice on best use of try catch throw
aao wrote:
- I can't initialize a constant with the result of this function.
why not?
Isn't that obvious? The function doesn't deliver its result via return, so
it is impossible to initialise a constant with it.
int const x = foo();
From this code I know that the value of x won't change throughout its
lifetime, which helps understanding code sometimes. If foo() took a
reference to an int, I wouldn't know that. Further, I would need another
variable to store the returncode.
- It forces me to clutter my logic with the checking of returnvalues,
i.e. this is a maintenance overhead.
This is not an argument , because from my view I "clutter my logic"
with try catch
The point is that you don't. Typically, you have nested function calls
several levels deep. Now, when the innermost one detects an exceptional
condition and thus can't continue, it simply throws an exception. If
neither of the upper functions handles the exception, the program is
terminated. If you use returncodes, you have to check the returncode in
each and every function, regardless of whether you handle the error or just
return it.
Let me get this straight:
You don't replace this code
if( error_code e = foo(42))
return e;
if( int i = bar(3.14f))
return convert_to_errorcode(i);
with this code
try {
foo(42);
} catch( std::exception const& e) {
throw e;
}
try {
bar(3.14f);
} catch( std::exception const& e) {
throw e;
}
Instead, you simply use this code:
foo(42);
bar(3.14f);
At a high level, typically in main() or close to it, you might do this:
try {
foo(42);
bar(3.14f);
} catch( std::exception const& e) {
std::cerr << "exception: " << e.what() << std::endl;
}
but all the intermediate checks of returncodes simply vanish! Of course, if
you need to do manual cleanup of resources, you have to catch and then
rethrow the exceptions, but then you already did something wrong and that
is not to use RAII.
- It encourages less good programmers to ignore possible errors.
As I said forcing you users to do error recovery mode might discourage you
users from using your library at all(I know I am such a user myself)
Well, if you can't continue due to an error you must not do so, right? And
in that case, it doesn't matter if that is signalled with a returncode or
an exception, but you can't accidentally continue after an exception, you
have to explicitly acknowledge it.
- Recurring checks of returnvalues are an unnecessary performance
overhead.
Do not start me on performance - in 99.9% of the cases exceptions create
huge overhead (try any kind of performance measurement on such a code)
I did, and there is no overhead in the non-exception case. Maybe you did
with an old cfront-based compiler, but even the ten year old MSC 12 is
better than that. Calling exceptions a huge overhead has long ceased to be
true.
- Exception can carry much more information than a HRESULT. If you
replace it with a different struct, the performance penalty increases
further.
example would help. As far as I know HRESULT encoding is very
informational. What is missing in your opinion?
if(not in.open(filename.c_str()))
throw std::runtime_error("foo() failed, '" + filename
+ "' was not available");
And, I may point out, this comes at no additional cost in the
non-exceptional case! If you tried to achieve this with with returncodes,
each of them would have to carry useless additional information in the
non-error case.
Uli