Multiple Catch blocks that do the same thing...
-
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:
:)
-
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
-
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.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...
-
Hi CP community. We hired a guy that did this a while ago. It annoyed me then, and now I have a project that I'm refactoring that lo and behold has it as well. Maybe I'm missing some recommended practice (I googled it), and I don't mean to start a war or anything. I just don't see an obvious use for things like this. The message is the same when a socket error occurs...
try
{
DoSomething();
}
catch (SocketException e)
{
Console.WriteLine(e.Message);
conn.connecting = false;
}
catch (Exception e)
{
Console.WriteLine(e.Message);
conn.connecting = false;
}What purpose in life, universe, code, etc... does a practice like this serve?! (Clarification for all of those who've been giving concrete reasons for catching different exception types. I get that. I do that as well. I'm saying that the guy we hired previously would handle several exception types only to do the same thing as the catch-all block. Literally the same thing. Sometimes he would catch a type only to throw it to the main block doing nothing with the specific type. It bugged the hell out of me. Now I'm refactoring another project that is completely unrelated and I see a similar practice which made my mind wander to here...)
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!
-
Hi CP community. We hired a guy that did this a while ago. It annoyed me then, and now I have a project that I'm refactoring that lo and behold has it as well. Maybe I'm missing some recommended practice (I googled it), and I don't mean to start a war or anything. I just don't see an obvious use for things like this. The message is the same when a socket error occurs...
try
{
DoSomething();
}
catch (SocketException e)
{
Console.WriteLine(e.Message);
conn.connecting = false;
}
catch (Exception e)
{
Console.WriteLine(e.Message);
conn.connecting = false;
}What purpose in life, universe, code, etc... does a practice like this serve?! (Clarification for all of those who've been giving concrete reasons for catching different exception types. I get that. I do that as well. I'm saying that the guy we hired previously would handle several exception types only to do the same thing as the catch-all block. Literally the same thing. Sometimes he would catch a type only to throw it to the main block doing nothing with the specific type. It bugged the hell out of me. Now I'm refactoring another project that is completely unrelated and I see a similar practice which made my mind wander to here...)
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 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. -
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...
See my reply here. [^]
-
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.connectingwith abool connectingor 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
-
Take the code from the original post and put it into Main() of a new console project. Replace
conn.connectingwith abool connectingor 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.
-
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
-
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.
