|
|
To your second example, the easier solution would be not to have a "general" catch block at all, right?
try
{
}
catch(SQLException sqlex)
{
}
On the other hand, the opposite really does require a rethrow:
try
{
}
catch(SQLException sqlex)
{
throw;
}
catch
{
}
|
|
|
|
|
You could leave out the general catch but personally I prefer to have it there as I think it leads to the readability of the code, also I generally don't have a general catch that re-throws the exception without logging the exception in some manner such as the first example I showed.
People are more violently opposed to fur than leather because it's safer to harass rich women than motorcycle gangs
|
|
|
|
|
You can also use re-throwing an exception to add more information e.g.
public void SomeFunction()
{
try
{
// Do stuff
}
catch (Exception e)
{
// Do logging
throw new Exception("Some additional informative text.", e);
}
}
I've used this technique before, you just need to remember to walk the nested exceptions (InnerException) when you finally process the Exception.
Kevin Rucker, Application Programmer
QSS Group, Inc.
United States Coast Guard OSC
Kevin.D.Rucker@uscg.mil
"Programming is an art form that fights back." -- Chad Hower
|
|
|
|
|
Rod Kemp wrote: try {
// code that may throw exception here
}
catch(SQLException sqlex)
{
//Handle this exception here
//Don't re-throw the exception
}
catch {
throw; //re-throw all other exceptions that may occur
}
You really should not have put in the generic catch in this case. While cycles are cheap, this throws many cycles away for no reason. Simply catch those you are interested in and let the others roll up. No need to catch them if you plan to do nothing but throw them.
|
|
|
|
|
I never said this was production code but rather a way to teach an inexperienced developer about exception handling which should go beyond try/catch blocks and also incorporate defensive programming, maybe you should read the rest of my comments.
That said, during normal operation having the general catch block has no impact on performance it is only when something goes wrong that it may take a few cycles to propagate the error, but honestly if you're bothering to optimise your code at that point you really need to get out more.
People are more violently opposed to fur than leather because it's safer to harass rich women than motorcycle gangs
|
|
|
|
|
If he doesn't even know what she meant by 'add exception handling' - how much do you think he is going to be able to tutor her
Life goes very fast. Tomorrow, today is already yesterday.
|
|
|
|
|
It does actually get worse. I've seen
public int FormatSomethingOrRather(string txt)
{
try
{
}
catch (Exception)
{
}
}
That took about a day to track down the bug it was causing. So after fixing I ran FxCop and found dozens
|
|
|
|
|
Obviously the exception should be handled recursively, so that when it's thrown, it's caught again. But if it's an inexperienced developer, I can understand this mistake.
|
|
|
|
|
|
|
I think
doja93 wrote: she, "..wanted to add exception handling.." to her code
already show she has potential, just need some guidance... I've seen very few developers who WANT to add exception handling to their code...
I did this article, readers seemed to have found it informative: Exception Concepts for Business Applications
I'm way over due to continue with a second article, I know...
____________________________________________________________
Be brave little warrior, be VERY brave
|
|
|
|
|
That's the best answer I have seen yet. sometimes writing code is not about making it work, but how to handle things when they don't work.......
|
|
|
|
|
I think this is not real. Understandable you cut the actual do something code but where is your semi-colon after the 'throw e'
I assume you typed this code, maybe you missed an important bit of catch code
Life goes very fast. Tomorrow, today is already yesterday.
|
|
|
|
|
Yoy. At least they used camel casing
static void AddEquipment(object dontUseThisWeHaveToDeleteThisMethod)
The parameter isn't used in the method...I think that the guy must've added the param to the method to make other code break (maybe using the compiler to find where it was called from) and then basically abandoned the code. Didn't comment anything or comment the code out or anything.
I think I'm going to start using gems like this for NEW methods. Just sprinkle a couple of these across new APIs and let people wonder...
|
|
|
|
|
I like that!
A former collegue of mine had a tendency to use very long and elaborate variable/function/method/property names. One day i invented an unused property called __AVeryLongAndLargelyUnusedProperty_PKA. PKA being his initials. Need i say that i forgot all about it. The thing went into production, until years later PKA one day yelled at me: What the shikes is this?
|
|
|
|
|
Looks very brownfield to me
(yes|no|maybe)*
|
|
|
|
|
public int F ( int Reserved ) ...
|
|
|
|
|
Hmmm, let's improve it!
static void AddEquipment(object dontUseThisWeHaveToDeleteThisMethod)
{
if (dontUseThisWeHaveToDeleteThisMethod is bool && (bool)dontUseThisWeHaveToDeleteThisMethod) return;
}
Seems better?
|
|
|
|
|
|
Hockey is the greatest sport in the world.
It's Movember, Mustache competitions are important, as they are to raise awareness for prostate cancer.
And a career like taxes in Canada sounds AWESOME! Where do I apply?!
|
|
|
|
|
GibbleCH wrote: Hockey is the greatest sport in the world.
Boxing is the greatest sport. It gets past all that silly foreplay and you get to see what you came there to see... the fight!
|
|
|
|
|
The most ruthless game I've ever played is Croquet. It looks genteel, but you constantly have to F@*k your opponents as much as possible over to win.
Don't confuse Cricket with Croquet[^]
|
|
|
|
|
I did play croquet in my backyard when I was younger. Maybe that's why I always make miniature golf a full-contact (as far as our balls are concerned) sport.
|
|
|
|
|
Leave my balls alone, would you...
(You're all thinking it, I just had the balls to say it)
I wasn't, now I am, then I won't be anymore.
|
|
|
|