|
|
I used to have a developer who did his try/catch routine like this, thinking that as exceptions were caught "in the wild", he would fill in his catch clause. I had to show him that if he left his catch clauses open, none of the exceptions would be handled.
At the very lease, rethrow the original exception. The most effective method I've used is to go through all your activities in the try clause and look for all the different exceptions you are capable of throwing, and then trap those exceptions one at a time and recast the exception with a more descriptive message with any relevant values and capture the original exception as an inner exception so you don't lose the stack trace. And finish it with a catch-all.
It's a paranoid way of writing your catch clause, but OMG my operations guys were the first converts because they didn't have to go through the stack trace and data dumps...it's all right there in the message. It also makes for very effective unit tests too, since you can predict just every aspect of where the routine could break rather than some obtuse unhandled null reference exception.
|
|
|
|
|
error checking is hard, especially in embedded systems. in 14 years of development, I have not yet heard of a cogent approach to how to fail creatively. That said, the *minimum* error handling should be a log message saying "you're f****" and why  . Hopefully with some minimal thought, you can come up with a recovery approach...
Charlie Gilley
<italic>Stuck in a dysfunctional matrix from which I must escape...
"Where liberty dwells, there is my country." B. Franklin, 1783
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
|
|
|
|
|
I dreamed I got the source code for my life, but forgot to check for errors and my entire life is a major debugging process.
CQ de W5ALT
Walt Fair, Jr., P. E.
Comport Computing
Specializing in Technical Engineering Software
|
|
|
|
|
Life is like a game of chess.
I don't know chess.
|
|
|
|
|
So you want to play catch?
?Maybe I should try throwing again?
CQ de W5ALT
Walt Fair, Jr., P. E.
Comport Computing
Specializing in Technical Engineering Software
|
|
|
|
|
bool flags[2];
if ( (flags[0] == true) ||
(flags[1] == true) )
{
if ( (flags[0] == TRUE) ||
(flags[1] == TRUE) )
{
}
}  I just found this in some code I have to extend to support a new feature. I wonder if Mike Rowe[^] knows C++...
Software Zen: delete this;
|
|
|
|
|
One can never be too sure
noop()
|
|
|
|
|
Check them in the outer...then checks them in the inner??? 
Sheer Poetry He's checkin' his flags,
he's checkin' them twice.
He knows if them flags
have been naughty or nice!
|
|
|
|
|
Yes, and the flags aren't changed anywhere inside the intervening 'logic'.
Not only does he compare a bool to true, he also compares it to the Windows-defined TRUE as well, which is not really the same thing.
Software Zen: delete this;
|
|
|
|
|
What if, 15 years down the line, someone inserts code between the two different checks that changes the value of TRUE?
You have to make absolutely sure that it is still true when the really important piece of code hits. I suggest you add a few inline ifs so that there will never be any doubt.
My plan is to live forever ... so far so good
|
|
|
|
|
To quote my "favorite comment":
#define TRUE FALSE
"Never attribute to malice that which can be explained by stupidity."
- Hanlon's Razor
|
|
|
|
|
|
Oh no, that can be not only valid, but also necessary...
Can you be sure that there's not some strange #define somewhere changing the meaning of TRUE or true?
And when the flags array is a member of the class (instead of locally declared in a function), its values can be changed from where ever in a different thread.
Just make sure you cope with such threats.
Oh sanctissimi Wilhelmus, Theodorus, et Fredericus!
|
|
|
|
|
Bernhard Hiller wrote: #define somewhere changing the meaning of TRUE or true?
Even more reason to break out the flamethrower... 
Software Zen: delete this;
|
|
|
|
|
Hey, I recently removed code toying with the global BoolStr variable because some table-internal-to-the-program had to use yes/no instead of true/false which as easily readable but doesn't require meddling with globals.
|
|
|
|
|
just add this code before the first if statement:
if (flags[0] == TRUE) flags[0] = true;
if (flags[1] == TRUE) flags[1] = true;
if (flags[0] == FALSE) flags[0] = false;
if (flags[1] == FALSE) flags[1] = false;
Then you can trust !(not), && and || for the rest of the checks.
Or better yet, with 2 Booleans, there are only four possible states, so normalize and then turn it into a switch statement with 0-3.
if (flags[0] == TRUE) flags[0] = true;
if (flags[1] == TRUE) flags[1] = true;
if (flags[0] == FALSE) flags[0] = false;
if (flags[1] == FALSE) flags[1] = false;
int state;
if (flags[0])
state = 1
else
state = 0;
if (flags[1]) state += 2;
switch (state) {case 0-3:...}
|
|
|
|
|
My gastrointestinal tract just inverted itself...
Software Zen: delete this;
|
|
|
|
|
Even worse:
If the //... code that initializes the flags array really assigns those values into it, then it looks like the original code does not even consider these cases:
x == true && y == TRUE.
2 variables with 4 possible values each means there should be 16 possible states.
Normalizing the values reduces it to 2 variables with 2 possible values which gives 4 states.
If true vs TRUE produce different outcomes, then God bless you and convert the "bools" into an enum.
Consider creating a multidimensional array where the indexes are your "flags" and you initialize each array element to be the correct answer for that combination of states.
|
|
|
|
|
Is it possible we're talking about Quantum bool ????
Paulo Gomes
Measuring programming progress by lines of code is like measuring aircraft building progress by weight.
—Bill Gates
Everything should be made as simple as possible, but not simpler.
—Albert Einstein
|
|
|
|
|
Only this[^] knows.
Software Zen: delete this;
|
|
|
|
|
Maybe it's an existential program looking for the meaning of truth and it couldn't get a hold of Stephen Colbert.
|
|
|
|
|
Both patterns are bad. On most platforms bool is an integer. Therefore flags[x] might get corrupted to equal, say 42. Code that didn't explicitly check consistently for "==true" would take the wrong path. if(flags[x]) would be true, if(flags[x]==true) would be false. Then you also get the VB true, which is -1!
|
|
|
|
|
what if var TRUE = false; hey!? I betcha didn't think of it, did ya?!  
|
|
|
|
|
This is C++, fortunately.
Software Zen: delete this;
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
