|
Are you saying the message will always be the same ?
This is a trick, If you do get it. 
|
|
|
|
|
Yes. The message comes from the Exception object, and will the same regardless of which catch block catches it: for a SocketException it will print a socket based message, for an AliensLandedOnWhiteHouseLawnException, it will print a message in Klingon.
But it is irrelevant which catch block prints it, because they both use the same code to do that.
There is only any point in having separate catches if they do different things:
catch (SocketException e)
{
Console.WriteLine("Problem with socket: {0}", e.Message);
conn.connecting = false;
}
catch (Exception e)
{
Console.WriteLine("An unknown error occured: {0}", e.Message);
conn.connecting = false;
}Or even:
catch (SocketException e)
{
Console.WriteLine("It's life Jim: {0}", e.Message);
conn.connecting = false;
}
catch (AliensLandedOnWhiteHouseLawnException e)
{
Console.WriteLine("Klingons on the starboard bow, starboard bow, starboard bow\nKlingons on the starboard bow, starboard bow Jim!: {0}", e.Message);
conn.connecting = false;
}
catch (Exception e)
{
Console.WriteLine("But not as we know it: {0}", e.Message);
conn.connecting = false;
}See what we mean?
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
The fact that you still ignore the Dosomething() method do, you generalize that both catches block get the same exception. Even I gave you example that the method might throw DBException and you expect the SocketException get exception based on your assumption.
|
|
|
|
|
I don't need to know what DoSomething() does to reason this:
original code:
SocketException > catch block 1 > { Console.WriteLine(e.Message); conn.connecting = false; }
other Exception > catch block 2 > { Console.WriteLine(e.Message); conn.connecting = false; }
after removing catch block 1:
SocketException > catch block > { Console.WriteLine(e.Message); conn.connecting = false; }
other Exception > catch block > { Console.WriteLine(e.Message); conn.connecting = false; }
ergo: catch block 1 is redundant
If the brain were so simple we could understand it, we would be so simple we couldn't. — Lyall Watson
|
|
|
|
|
Yes you do need to have the catch block. In fact you may need to add more based on what Dosomething()does. What op need to do is to implement the appropriate logic in the catch block which I already said it in my first response.
|
|
|
|
|
Take the code from the original post and put it into Main() of a new console project. Replace conn.connecting with a bool connecting or throw it out. Instead of DoSomething() throw a SocketException or create a method DoSomething() and throw the SocketException there. Run it and take note of the console output. Remove the first catch block and run again. You'll notice that it's the same output. Ergo the first catch block is redundant in this particular code sample.
If the brain were so simple we could understand it, we would be so simple we couldn't. — Lyall Watson
|
|
|
|
|
No that is not the intension. Op misses to implement the appropriate logic behind once the error occurred in SocketException which he copied similar catch block in the Exception block.
|
|
|
|
|
True. But you missed that we were explicitly not talking about how it should be done right but about whether the two catch blocks make sense the way they are.
If the brain were so simple we could understand it, we would be so simple we couldn't. — Lyall Watson
|
|
|
|
|
They make sense since the Op knows that there is socket related exception which Op wrote to it's own catch block. To me the the code was only getting SocketException for a while and then he got other excepion which it couldn't caught by SocketException and then he added the same catch code block with Exception without taking the account of future coders since he got relief at that moment.
|
|
|
|
|
No, I don't.
But both catch blocks have the same code.
So they both do the same thing regardless of which exception gets fired.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
|
I assume we're talking past each other. The question isn't if catch blocks catching different types of exceptions can be useful but if it's of any use in this concrete case - which it isn't because the exceptions aren't handled differently.
If the brain were so simple we could understand it, we would be so simple we couldn't. — Lyall Watson
|
|
|
|
|
Member 11394652 wrote: SocketException sex
Cheers,
विक्रम
"We have already been through this, I am not going to repeat myself." - fat_boy, in a global warming thread 
|
|
|
|
|
|
There is a recommended practice where you catch the minimum exception you can: SocketException instead of Exception for example, but that code's silly.
It's possible that he planned to come back and do something different for the SocketException later and never got round to it, but if that's the case the author still needs a thump upside the head... 
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
OriginalGriff wrote: It's possible that he planned to come back and do something different for the SocketException later and never got round to it
That was my thought exactly. 
There are only 10 types of people in the world, those who understand binary and those who don't.
|
|
|
|
|
The only thing I can think of is that he didn't know that both were the same and just wanted to keep a separation of concern?
New version: WinHeist Version 2.1.1 new web site.
I know the voices in my head are not real but damn they come up with some good ideas!
|
|
|
|
|
Typically you would want to handle a socket exception different than a general exception. Maybe an oversight in this case that both are handled the same way. Might have been put in there for debugging.
|
|
|
|
|
Well, that could have been more interesting, e.g.
catch (SocketException e)
{
Console.WriteLine(e.Message);
conn.connecting = false;
throw;
}
catch (Exception e)
{
Console.WriteLine(e.Message);
conn.connecting = false;
}
|
|
|
|
|
Just useful while debugging; you can have a breakpoint in one block but not the other; but it should be removed afterward.
|
|
|
|
|
Looks like code I would have written except that I would have put a TODO in the SocketException handler with a note to do something more useful than what the generic exception handler does. Or the other way around. Either way, the intention would be to come back later and fix it.
Marc
|
|
|
|
|
I'd lay odds that the original programmer thought he may 'legitimately' get a socketException error, so catches it and handles it appropriately. (though in this case, just logs it)
But then wants to catch and log any other exception, just in case.
So the fault is in the fact that in the 1st catch he should probably have been putting some relevant code (I dunno - pop up a message to the user or something) as it is an 'expected' exception.
As I think Marc said - looks like a TODO is missing!
PooperPig - Coming Soon
|
|
|
|
|
I read about the "GWX"-Advertising (Get Windows 10) "Update" for Windows 7/8 before I confirmed installing updates - so I selected the "ignore" option for that one.
Guess what - now I have that friggin thing in my taskbar anyway, probably because there was another such "update" for Windows 7.
Alright - the FAQ says:
Q: Can I turn off the notifications?
A: Yes. Click “Customize” in the System Tray and turn off the Get Windows 10 app notifications in the menu that comes up.
So I turn it off.
After next reboot: It's there again.
What the ??? 
If the brain were so simple we could understand it, we would be so simple we couldn't. — Lyall Watson
|
|
|
|
|
Microsoft has really become somthin.
What that somthin' really is I'm afraid is yet to be seen. 
|
|
|
|
|
Go in Control Panel, Windows Update...click on 'Installed Updates' link at the bottom left of the window. In the list of Installed Updates, find KB 3035583, right click it and choose 'Uninstall' and poof!, it's gone 
...after this, do a new check for Updates, you will find it in the list again, right click it and choose 'Hide Update'...that way it won't come up for install again.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
