|
Instead of returning a number I prefer to return an enum value since they are self-describe with their name and easily cast/store/serialized into a number.
|
|
|
|
|
...that it's their fault for running your app on a Tuesday.
|
|
|
|
|
Jeremy Falcon wrote: it's their fault for running your app on a Tuesday
|
|
|
|
|
Cover up the mess and don't say anything
As of now it's 9.7 and 4.18 and this shows how unexpected stuffs are handled by some developers. And it has even beaten first option.
Q1. For non-critical errors:
Set a global error flag 13 2.47
Return a reserved value 161 30.61
Return an encoded error value (eg HRESULT) 88 16.73
Throw an exception 211 40.11
<code>Cover up the mess and don't say anything 51 9.7 </code>
Total 526 100%
Q2. For critical errors <code>that leave the app in an undefined state</code>
Set a global error flag 19 3.61
Return a reserved value (0 or -1 etc) 40 7.6
Return an encoded error value (eg HRESULT) 38 7.22
Throw an exception 401 76.24
<code>Cover up the mess and don't say anything 22 4.18 </code>
Total 526 100% Look at the second question, it says it leaves the app in an undefined state but 22 have voted for covering up!
It will be interesting to see how they cover up. One of the cover up mechanisms that I have seen is...
try
{
}
catch( ... )
{
return false;
}
|
|
|
|
|
Provide an option to the user:
"An unhandled exception has occurred. Would you like the responsible programmer (who is probably browsing the CP lounge right now) to be automatically fired?"
[ YES ] [ NO ]
"For fifty bucks I'd put my face in their soup and blow." - George Costanza CP article: SmartPager - a Flickr-style pager control with go-to-page popup layer.
|
|
|
|
|
Hu ? Well, sorry, noooooooooooo, not meeeeeee !
Kochise
In Code we trust !
|
|
|
|
|
So thats why this giant boot was installed above my head..... ohhh $*#&@& i'm not going to program on Mondays any more...
|
|
|
|
|
Your company is running out of programmers. How do you want to react?
<Fire the last one> <Hire a new one> <Re-Hire a fired one> <Fix the bug yourself>
____________________________________
There is no proof for this sentence.
|
|
|
|
|
<Redirect yourself in a new business>
Kochise
In Code we trust !
|
|
|
|
|
Get New job 
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
Support CRY- Child Relief and you
|
|
|
|
|
Andrei then presented an intriguing proposal - an alternative approach which combines some of the better characteristics of both. I won't go into it further other than to say it was an intriguing proposal involving a template type called Likely<T>.
If anyone wonders, a PPT of the presentation by Andrei and Petru about the classes None and Likely<T> is here[^]
It's a continuation of the "exception bomb" eturn values they (and I think Scott Myers) have been throwing at each other lately. Interesting concept, definitely.
|
|
|
|
|
Wouldn't it be more efficient if r == None() would be replaced with r.IsNone() ?
|
|
|
|
|
Display a big pop-up stating :
Windows is too weak to handle that marvelous and powerful application you have bought from us, better switch for a real operating system. Oh, and the Unix and/or MacOS version just costs the double, if ever we have released one...
Button : [Bad day]
Kochise
In Code we trust !
|
|
|
|
|
When there is an error, I do the following (from highest priority to lowest):
See if the code can recover from the error. If it can, recover from the error, log it, and continue.
If the recovery was successful, but leaves some other non-critical mess behind, try to clean it up or notify the user.
If the mess kills of a part of the application (like a plug-in) try to kill it and restart the affected part.
If there is no hope of recovery, pop up a suicide note and die.
In the worst case scenario, it dies without leaving any clue behind as to what happened.
ROFLOLMFAO
|
|
|
|
|
Behind The Scene wrote: If there is no hope of recovery, pop up a suicide note and die.
never heard it referred to in that manner before... LMFAO!
got my 5 for that alone.
|
|
|
|
|
This reminded me of a question that I've had for a while and this seems like the perfect opportunity to ask...
CString throws exceptions.
How many of us (That use CString) put those puppies in a try/catch?
|
|
|
|
|
|
Honestly, that was meant as a rhetorical question. It's just entertaining how many of us will insist on preventing memory exceptions elsewhere in our code, kinda a slippery slope argument of sorts, then turn around and slap 50 different CStrings into various methods of our classes and insist that it would be overkill to worry about it.
I'm sitting on the fence on this one myself but some of us can only look at ourselves, our rational for our different standards, and laugh.
It's amazing how we convince ourselves that it is justified to be selective about what to catch and when it's not something we should worry about.
|
|
|
|
|
well back in the days of MFC/C++ programming, the alternative would be using a char[]. However I never had a problem with CStrings giving me exceptions... maybe i was lucky, but i thought it solid.
|
|
|
|
|
generally don't play with Cstring boundry much.. never faced exception due to CString for last three of my MFC programming life!
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
Support CRY- Child Relief and you
|
|
|
|
|
... for signaling failures to a top level from deeply nested/recursed logic. You don't have to rely on intervening layers to correctly handle and return error conditions.
For example, I use MSXML (stop laughing  ) in a 'document' class to handle XML. Outside the class, I'm only interested if a document failed to load or not. Using exceptions, the error handling is clean and simple. If I used the 'return an error code' model, it would be a heck of a lot more complicated, and the code would be an order of magnitude bigger.
Software Zen: delete this;
|
|
|
|
|
Gary Wheeler wrote: I use MSXML
That happens to be to be the item that got me to finally appreciate how much effort an exception can save me with deep nesting. Put the try at the top level of the dom walker and let it go.
Elsewhere, though I've found little use for them but I'm sure I'll find another someday. Exceptions are definitely not as common in my code and more of a nuisance in general.
|
|
|
|
|
I agree that for deeply nested hierarchies, exceptions are a blessing. However, they come with so much trouble that they rarely pay off.
|
|
|
|
|
peterchen wrote: However, they come with so much trouble that they rarely pay off.
Care to elaborate?
|
|
|
|
|
sorry for the delay - my internet connection went down yesterday..
First - this is not C++ specific - many comparisons of Error Code vs. Exceptions is biased by comparing non-RAII C code to RAII-based C++ code. using RAII simplifies the code - whether you exit with a return E_SomethingWentWrong;, or with a throw invalid_exception("Something went wrong");. Just check your local C++ book.
Second, C++ - specific: excpetion-safe code is hard to write, and almost impossible for templates. For a few starters (or maybe they are just arguments by authority...):
Writing correct Exception-based code is hard[^]
Another one[^]
A false sense of security[^] - the "famous stack invitation". Turns out you can't write an exception safe stack class template that offers T pop()
Third, "throwing from the deepest innards of that complex call tree" is certainly powerful and often welcome, but it is generally not useful. because getting an "array index out of bound" exception from the innards of RenderAllScenes() will neither help the user working arounf the problem, nor will it help you diagnose it. Even having a call stack here (like you get in C#) doesn't help much for nested loops. You need to catch, repackage and rethrow the exception at various levels to make it more useful than just "the grue is in there, lucky we made it out alive".
Also, these ugly complex algorithms often have a fallback mechanism what to do if they don't fin the file.
Fourth - C++ - specific again - in a normal (i.e. non-simplistic) application, exceptions don't propagate. They don't propagate across COM calls, across DLLs or Windows Messages (and don't even think of thread or process borders). And that's the places where I code in C++.
I am not trying to bash Exceptions, I am just trying to move them into perspective. They are good, because you can't really ignore error handling when calling code, but it makes it so easy to forget about fallback strategies and just throw up your arms in despair when you are writhing the code to be called.
just my thoughts.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
