Re: Exception Misconceptions: Exceptions are for unrecoverable errors.
In article <hgqqon$osi$1@news.albasani.net>, Vladimir Jovic <vladaspams@gmail.com> wrote:
Stefan Ram wrote:
[snip]
More elegantly? Actually, for correct and secure C++ code,
all functions need to be written to be ?exception safe?, but
only a minority of C++ programmers does so or even is aware
of it.
Why?
I thought only the code in the catch blocks have to be exception safe.
Might be new exception misconception ;)
The code in your catch block is not necessarily exception safe.
It all depends what are you going to do to recover from the
original exception. You MAY get yet another exception when
trying to recover from the original one.
In some places in my code, I have nested exceptions.
Acutlly in quite a few MOST important places.
That is why this thing runs like a tank.
You can just turn the power switch on in the middle of the
most important and critical and time consuming operation.
[snip]
Futher discussion of the application of exceptions is
appreciated.
I prefer error results to exceptions. So all I would write
about exceptions would start with ?If I was forced to use a
language that would force me to use exceptions ...?
The applications of error results is as follows:
This should have probably been "switch" instead of "if" :
if( attempt( to_do_something ))
{ case 0: /* ok, continue */ ... break;
case 1: /* oops, handle */ ... break;
... }
Back to return value vs exceptions.
1)
What happens if you can not handle the error in this method?
Correct, and it is not such an uncommon thing.
Because, first of all, the error is local.
Your routine does not necessarily know what is the most
logical thing to do on the HIGHER levels.
So, what is the solution then?
If you just return an error code, then the higher level
code has to examine it, and do different things, which simply
translates in additional and unnecessary complications in
your program logic, a "spaghetti effect".
You may have 5 levels deep stack, and on EACH level, you
have to test every single return code. Else your program
is incorrect.
So, you tend to forever deal with small and insignificant
things in the scheme of things, all of which, regardless
of how many levels deep on the stack it happened, could
be handled in bulk, with a single exception at the
appropriate higer level, that gives you sufficient
granularity to make a LOGICAL decision on what can be
done to recover the operation as such, and not some low
level funk, which is nothing more than a logic noise.
I am trying to use as little of logic as possible.
My slogan is: take it easy on your logic,
or you are bound to end up with grand headache,
no matter from what standpoint you look at it.
It will simply make your code more difficult to read.
How many decisions does you mind have to make, if it
forever worries about whether some return code was
handled correctly, of was handled in the right place
or what kinds of problems it might cause to the higher
level code.
Program logic = load on the mind.
Or in the method that called this method?
Or in the method that called the method that called the method where the
error happened?
etc
2) How do you handle errors in constructors?
You don't. Because you can not construct the object.
Your program is incorrect, and I doubt you can recover
from this kind of thing in principle in most cases.
3) Simple example : how would you create a method (or a function) that
reads a value (some random integer) from a file and returns that value?
--
Programmer's Goldmine collections:
http://preciseinfo.org
Tens of thousands of code examples and expert discussions on
C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript,
organized by major topics of language, tools, methods, techniques.