Multiple Catch blocks that do the same thing...
-
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...)
-
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...)
jeeves77 wrote:
What purpose in life, universe, code, etc... does a practice like this serve?!
Zero :laugh:
If the brain were so simple we could understand it, we would be so simple we couldn't. — Lyall Watson
-
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...)
-
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...)
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... :laugh:
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
-
Yes it has purpose. You should see this msdn article. [^] But it wasn't utilized as suppose to.
I looked, I saw: but I didn't see a purpose to having two exception catchers that do the same thing. Yes, if the SocketException catcher logged it differently, or re-tried or similar, and the Exception catcher did a generic log-and-exit instead then it's would have a purpose. But two exceptions (one of which catches everything) that do the same thing? I see no point, except to duplicate code and potentially cause a maintenance problem if the logging mechanism changes.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
-
I looked, I saw: but I didn't see a purpose to having two exception catchers that do the same thing. Yes, if the SocketException catcher logged it differently, or re-tried or similar, and the Exception catcher did a generic log-and-exit instead then it's would have a purpose. But two exceptions (one of which catches everything) that do the same thing? I see no point, except to duplicate code and potentially cause a maintenance problem if the logging mechanism changes.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
We can't predict looking the above code since we don't know what
Dosomething()method exactly do. What we can infer is that there is a socket processing behind since there is a catch exception on it. -
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...)
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!
-
We can't predict looking the above code since we don't know what
Dosomething()method exactly do. What we can infer is that there is a socket processing behind since there is a catch exception on it.It's irrelevant what DoSomething() does in regard to the catch-blocks. In case of an exception, either the first or the second catch block gets executed and they do exactly the same, so the more specific one is superfluous.
If the brain were so simple we could understand it, we would be so simple we couldn't. — Lyall Watson
-
It's irrelevant what DoSomething() does in regard to the catch-blocks. In case of an exception, either the first or the second catch block gets executed and they do exactly the same, so the more specific one is superfluous.
If the brain were so simple we could understand it, we would be so simple we couldn't. — Lyall Watson
They don't occur exactly with the same reason. Off course both catches exception but how each one will occur determine by the actual method logic. Suppose Dosomething() has DB process, then where you will think possible to be catched if error happens. On catch (Exception ex) block and where do you think the socket error will be catched on (SocketException sex). That is why the method logic determine the exception occurence.
-
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...)
-
They don't occur exactly with the same reason. Off course both catches exception but how each one will occur determine by the actual method logic. Suppose Dosomething() has DB process, then where you will think possible to be catched if error happens. On catch (Exception ex) block and where do you think the socket error will be catched on (SocketException sex). That is why the method logic determine the exception occurence.
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...
-
They don't occur exactly with the same reason. Off course both catches exception but how each one will occur determine by the actual method logic. Suppose Dosomething() has DB process, then where you will think possible to be catched if error happens. On catch (Exception ex) block and where do you think the socket error will be catched on (SocketException sex). That is why the method logic determine the exception occurence.
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
-
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...
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
-
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... :laugh:
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. :thumbsup:
There are only 10 types of people in the world, those who understand binary and those who don't.
-
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...)
-
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
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...
-
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...
-
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.
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...
-
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...)
Just useful while debugging; you can have a breakpoint in one block but not the other; but it should be removed afterward.
-
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...
