|
I think he missed "return iKey" in the finally clause 
|
|
|
|
|
If it's C#, you can't have a return in a finally clause.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
|
look at the code below:
int main(){
char *c=new char[10];
delete [10,05]c;
return 0;
}
compile fine in visual studio 2008
and error in gcc.
I wish I could believe there is an after life.
|
|
|
|
|
What happens during execution?
|
|
|
|
|
With Visual studio, work fine,
with g++ compilation error
I wish I could believe there is an after life.
|
|
|
|
|
It runs successfully without errors then... Wow! 
|
|
|
|
|
This is a (rather pointless) MS extension to C++: Pointless extension[^]
In your case, the comma operator will just throw away so the 10, so it becomes:
delete [05] c;
(Where 05 is an octal number)
And in fact will be ignored, rendering the result exactly the same as:
delete [] c;
"Ours not to reason why".
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
Sh** I remember that ','
I school days, first curse in all year using Visual C++... beautiful monitors of 14" at 1024*768...
We were calculating taxes for students based on Age and grade...
There were some students that were paying always 0.00 ... we debug (we were students, still stupids at debuging)... noting show wrong...
After like 5 hours... I went to play Ping Ping.. I returned, found my 2 teammates debugging.. then I notices and ask:
Guys is that payment * 0.05 or payment * 0,05... I learned that day that VC++ when 0,05 does Payment * 0 * 05.. then everything become 0!!!!
|
|
|
|
|
Let me start this discussion something like this:
Obviously, we need to catch only specific exceptions and that too if it is required.
But unfortunately this is not the case in my company. Here for each and every method (regardless it is required or not) you will find a single catch catching only the top Exception. Error logging is being done here and then sometimes it is being rethrown.
I dont understand this scheme/practice and hence I discussed regarding it with my Developers, peers, and Manager(s) but most of them say something like these:
--> 'It does not make any difference'
--> 'We are doing in this same fashion everywhere from beginning'
--> 'My TL asked me to follow like this'
--> 'It is a client's requirement to log all top exceptions all times and it should not be missed anytime'
Is any point from above is applicable?
Let's have some discussion please so that I get a broad and clear picture.
Thanks.
Understand SOLID! Believe SOLID! Try SOLID! Do implement live SOLID; your Code base becomes Rock SOLID!!!
http://www.codeproject.com/Articles/593751/Code-Review-Checklist-and-Guidelines-for-Csharp-De
|
|
|
|
|
Doesn't that go against the whole point of exception handling? try/catch is not equivalent of VB's On Error Goto.
Also if the code breaks all the time then its hardly an 'exception' is it?
And debugging must be a pain, as VS will break in catch block, not where the error occurred wont it?
How many of these catch blocks are entered on regular operation? Exceptions aren't cheap to throw after all.
Also is a try/catch block 'free' of any performance/memory penalty?
|
|
|
|
|
You raised very valid points. Thanks.
Understand SOLID! Believe SOLID! Try SOLID! Do implement live SOLID; your Code base becomes Rock SOLID!!!
http://www.codeproject.com/Articles/593751/Code-Review-Checklist-and-Guidelines-for-Csharp-De
|
|
|
|
|
cjb110 wrote: Also is a try/catch block 'free' of any performance/memory penalty?
It should be, certainly is in C++, and I'd imagine most later languages have been sensible enough to copy that implementation. Throwing exceptions has a definite overhead, but probably no more than writing the error code manually.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
The question is why do you catch exceptions at all... 
Most common answer is - to react to specific errors, for example - AccessDenied exception -> show message to user, SQLException - inform about DB problems or retry/abort and clean up..., etc.
In theory if application is properly writen, nothing unexpected should happen. But what if it happens?
You have two options:
1. Allow you OS/Framework show "unhandled exception" message - this annoys end users and makes troubleshooting harder as most users will close the window and will not report the details
2. Catch all otherwise unhandled exceptions and do something with them - log and rethrow or supress with generic error message and app shutdown/restart
Generally in development - this is not very good, unless you have a breakpoint in catch block or rethrow exception in debug config.
In production - I personally think this is good idea. For sure better than "unhandled exception" or empty catch block. 
|
|
|
|
|
That's a nice explanation Jarek!!! Thanks.
So you mean you support placing try/catch blocks everywhere and catching the main Exception everywhere, right? (But I'm still not supporting this practice) .
As you said, if it is properly written then no exceptions at all. But yes this is not the case always for some exceptions like MemoryOverflow, AccessDenied, etc. Therefore for only these kind of exceptions might specifically catch them.
Understand SOLID! Believe SOLID! Try SOLID! Do implement live SOLID; your Code base becomes Rock SOLID!!!
http://www.codeproject.com/Articles/593751/Code-Review-Checklist-and-Guidelines-for-Csharp-De
|
|
|
|
|
Mohammed Hameed wrote: So you mean you support placing try/catch blocks everywhere and catching the
main Exception everywhere, right?
Well it depens on your code structure...
Let's say you have the SaveRecord() method. This method is fired from UI and saves the record in DB.
Inside we have code dealing with database surrounded with try/catch(SQLException).
DB code throws SQLException as the DB is down, in catch we log the exception and throw custom RecordNotSavedExecption. UI part catches that and displays message to user.
Or returns false instead true, depending on your pattern.
That's the predictable and desired part.
Now if some other code in SaveRecord() throws OutOfMemoryException then we can:
1. Catch noting - we have OS/Framework unhandled exception. Bad.
2. We can catch all on application level (in one place in code), display generic error message to user, log the error and continue/close the app. Good.
3. We can catch generic Exception in SaveRecord(), log and throw custom RecordNotSavedExecption. Then we have above plus we just cancel the failing operation - not close the whole app. Better?
Mohammed Hameed wrote: But I'm still not supporting this practice
There are many patterns and practices, generally it's good to suport just one.
|
|
|
|
|
I'd tend to have exception-handling code mostly in one place, for example in a "SaveRecord" method - any exceptions raised in methods invoked by this can be caught here.
Putting exception-handling code in every method is overkill and leads to code being harder to read and maintain.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
Quote: Putting exception-handling code in every method is overkill and leads to code being harder to read and maintain.
My vote for this statement. Thanks.
http://authenticcode.com
|
|
|
|
|
I concur. Further, once the exception has been handled there should (normally) be no need to rethrow it.
This rule leads to the useful guidline: catch exceptions at the lowest level where they can be meaningfully (i.e. completely) handled.
The exception to the no-need-to-rethrow rule is when some cleanup action is needed as the stack is unwound. In that case, catch the specific type of exception, do the local cleanup only, and rethrow (ideally, using throw without a paramter - to preserve the stack trace). Do not duplicate the work that will be done in the can-meaningfully-handle-it catch block (such as logging, notifying the user, clearing context).
Note that the using (...){...} construct implicitly follows this rule: in the event that the contained block of code throws an exception, it will automatically invoke the Dispose() method on the item allocated by the using() statement.
|
|
|
|
|
Yes, I always liked C++'s RAII (Resource Acquisition Is Initialization) approach for exactly this reason. Every scope in C++ acts as an implicit "using" for all names declared within it, and the destructor is implicitly called when the scope exits. This gives deterministic resource management, but does leave more room for developer mistakes than managed languages.
While "using" does allow this (to a degree) in C#, to apply it to every resource would sometimes result in a cascade of nested "using" blocks. In C++, its all automatic.
Personally, I like to think I don't need my hands held by the compiler all the time.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
Is that to shorten the test period? IMHO one should go for defensive programming:
public double Divide(double term1, double term2){
double division = double.NaN;
if(term2 != 0){
division = term1/term2;
}
else{
division = double.Infinity;
}
return division;
}
instead of try/catch the DivideByZeroException.
|
|
|
|
|
Yes, that's applicable for user exceptions such as one you mentioned (DivideByZero) because developer already knows this fact and should handle it correctly in code like your example.
What about the system exceptions like MemoryOverflow, etc? This is not in control of developer to handle them.
Understand SOLID! Believe SOLID! Try SOLID! Do implement live SOLID; your Code base becomes Rock SOLID!!!
http://www.codeproject.com/Articles/593751/Code-Review-Checklist-and-Guidelines-for-Csharp-De
|
|
|
|
|
But shouldn't the developer *know* if a MemoryOverflow is a likely occurrence in a piece of code?
Otherwise we're saying that the underlying systems and framework are so flakey, that our apps might just randomly bug out...
That can't be a sensible approach to take surely??
For general code in most apps you have to trust the OS and framework will do as it always does.
|
|
|
|
|
Yes, developer does not know when the system resources like memory etc has crossed some threshold or system is short of memory. How do he/she come to know? As it can happen irrespective of whatever the code is being written.
Please, somebody correct me if my perception is not correct.
Understand SOLID! Believe SOLID! Try SOLID! Do implement live SOLID; your Code base becomes Rock SOLID!!!
http://www.codeproject.com/Articles/593751/Code-Review-Checklist-and-Guidelines-for-Csharp-De
|
|
|
|
|
memory exception for about 90% of the time, come from memory leaks caused by not releasing objects.
There are a few occasions were you could anticipate and act accordingly.
Furthermore, I hope there is some testing involved before going into production, any memory issues will come up there and you can act accordingly without the necessary need of exceptions.
Mohammed Hameed wrote: my perception is not correct.
it is not about right or wrong 
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
