you "that's not what you should do", and you continue to say "it's
broken if I do it".
What you should instead do, is let all your logic_error exceptions
propagate up to the highest possible stack level (e.g. main), catch
and terminate there (you could inform the operator/user that you
encountered a bug in the program). And perhaps not even that, perhaps
you should just let unhandled exception terminate the program (but
then, it's less clear what happened).
Why like this? Because logic_error means there is a bug in program
(and if it does not mean that, then the bug is that logic_error is
thrown when it should not have been thrown).
Goran.
If runtime_error is used instead in the example above, what's the
difference?
Yeah, fair enough ;-). You could use runtime_error, but it's probably
not the best idea. You should derive your exception classes from it.
As mentioned before, your derivation hierarchy should be wide, but not
deep.
Look at things this way: when there is an error (a real runtime error,
not programming error ;-)), what do you want your code to do? Most of
the time, you want to terminate a large chunk of processing as easy as
possible. Exceptions give you that in an easy way: you make a giant
try/catch, and catch errors somewhere at the far end of the operation.
You also probably want to inform your user what went wrong - using
std::exception::what() is there for it.
It is that I am just saying one thing that "throwing error is
potentially buggy" from the very beginning. While people kept saying
in various ways either the coding is itself buggy, logically
invalid, unqualified or it should be done differently, to make me
wrong or else.
I am sorry if that was your impression. It was not my intention to
make your point seem wrong, but to point out why your code snippets
are wrong. I mean, you really had a wrong approach in there, and you
got quite a few details completely wrong. Well, wrong code is wrong
irregardless of the use of exceptions.
Should I do this or do that is not the central topic,
which is again "throwing error is potentially buggy", particularly it
occurs throughout the standard library, most of them are low-level
functions, you have not shown any real remedy for that but diverse
the focus (from my view). I don't really want to talk about standard
library's fatal problem (not really fatal, if they are mostly
indicating programming errors themselves as you have demonstrated).
In my experience, if you receive an exception from standard library,
it's either bad_alloc, or an indication of a programming error (e.g.
range_error, stuff like that). I honestly see no problem whatsoever in
any exception thrown from standard library, hence there should be no
remedy. If it's a bad_alloc, well, you are out of memory, only thing
you can do is clean up while going up the stack and inform the user
that there's no memory - that's your remedy for bad_alloc. If it's
logic_error, there's a bug and it should be fixed by funding out
what's wrong and changing the code - that's your remedy for bugs.
What other remedy do you expect?
A skim of my remaining C++ teaching language books, including Bjarne
Stroustrup's and Herb Sutter's, all sample programs advocating
throwing errors (exception), no major returning error codes were found
. Many real programs in sourceforge can verify this, So I am in the
impression that the prevailing style is throwing errors.
Yes, in C++, it is. Situations where using error-return is interesting
are IMO seriously rare. Also, if you are using standard library, you
already work with exceptions. Many other C++ libraries, e.g. boost,
use exceptions to signal errors. So the reality is that you simply
can't escape exceptions with C++. operator new throws bad_alloc, STL
requires throwing operator new to work properly, simplest of things
like str1=str2+str3 might throw etc.
So you might try to use C++ libraries, but turn your own code into
error-return, but that would pretty much mean wrapping any function
you write, that use standard library and other libraries into giant
try/catch, and then turning that into error-return of your choosing.
That is IMO completely unwarranted and would result in a horrible
code.
Or, you may try to do C++ without exceptions, but then, for the code
to be "correct", it should not use standard operator new, standard
containers, string class and probably much more. Why would anyone
bother doing that is beyond me.
Goran.
opinion about the new type of error(programming error).
If I now understand you better. It may be from different stance and