Multiple Catch blocks that do the same thing...

[Jacquers]

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.

[OriginalGriff]

It doesn't matter. Regardless of what exception is thrown, the code executed will be identical. Which means that the separate catch for the "lesser" exception need not be there at all. And if it needed be there, why put it in? All that does is leave a "hole" where duplicated code can become different over time and cause other problems - that's one of the advantages of inheritance: it removes the need to "copy and paste" code by reusing a single method in all derived classes. So if the method needs to be changed, it's in one single place instead of scattered all over the file and prone to being missed when the updates are done.

Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...

[Sascha Lefevre]

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

[User 11360346]

We all know that managed .Net exception are derived from Exception class. If you are asking why the rest of derived Exception such as socketexception, Dbexception are created then that is another question. And it won't be necessary to allow multiple catch statement block from the compiler. Off course if you leave/comment out the above socketexception then the error definitely go to exception block, b/c of the reason that I stated above. Onething sure to know here, you can't determine to refactor the code by looking that code only, even we don't know either a SocketException will occur or not. G. Day

[ZurdoDev]

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. :thumbsup:

There are only 10 types of people in the world, those who understand binary and those who don't.

[CPallini]

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;
}

:omg:

[OriginalGriff]

It doesn't matter if a SocketException or an AliensLandedOnWhiteHouseLawnException occurs with that code: the code that is executed is identical regardless. That is the point. Not that Socket Exceptions are derived from Exception - we all know that - but that having a separate catch block is silly if the code executed is the same anyway! Look at the code. Assume a SocketException occurs in the method. What lines of code are executed? Now assume that a AliensLandedOnWhiteHouseLawnException occurs instead. What lines of code are executed? :laugh:

Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...

[User 11360346]

It does matter, a self ref [^] How do you know the code executed the same ? YOU DON'T KNOW WHAT THE METHOD(Dosomething()) DO. What we know both exception was not utilized as such.

[OriginalGriff]

Member 11394652 wrote:

YOU DON'T KNOW WHAT THE METHOD(Dosomething()) DO

Seriously, it doesn't matter. Look at the code we do have:

catch (SocketException e)
{
Console.WriteLine(e.Message);
conn.connecting = false;
}
catch (Exception e)
{
Console.WriteLine(e.Message);
conn.connecting = false;
}

The code in each catch block is identical. :laugh:

Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...

[PIEBALDconsult]

Just useful while debugging; you can have a breakpoint in one block but not the other; but it should be removed afterward.

[User 11360346]

Are you saying the message will always be the same ? This is a trick, If you do get it. :)

[Vikram A Punathambekar]

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 :doh:

[OriginalGriff]

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...

[User 11360346]

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.

[User 11360346]

:)

[Sascha Lefevre]

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

[OriginalGriff]

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...

[Marc Clifton]

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

Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project!

[Lost User]

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

[User 11360346]

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.