Comments on: TalesFromTheSmellySide<Code> – Episode #1 http://lostechies.com/joeybeninghove/2007/10/29/talesfromthesmellyside-lt-code-gt-episode-1/ Just another LosTechies site Fri, 15 Oct 2010 23:08:45 +0000 hourly 1 http://wordpress.org/?v=3.4.2 By: Sean Scally http://lostechies.com/joeybeninghove/2007/10/29/talesfromthesmellyside-lt-code-gt-episode-1/#comment-71 Sean Scally Tue, 30 Oct 2007 15:15:58 +0000 /blogs/joeydotnet/archive/2007/10/29/talesfromthesmellyside-lt-code-gt-episode-1.aspx#comment-71 @jssingh That is true; My problem with it is that it requires some things I don't like, such as code on both the client and server side to handle the wrapping and unwrapping of the exception in a uniform manner. I can't always make the assumption that the service is being used by someone that knows how to unwrap the exceptions properly, or even has the capability to do so. The real problem is that the WS/SOAP specs don't allow for robust exception handling, and my understanding is that future versions of MS WebServices/WCF lets you express exception data as part of the service descriptor, which makes this whole ugly mess unnecessary :) I sure have gotten far from the topic at hand. Back to smelly code! I may have to write a lengthier response later. @jssingh

That is true; My problem with it is that it requires some things I don’t like, such as code on both the client and server side to handle the wrapping and unwrapping of the exception in a uniform manner. I can’t always make the assumption that the service is being used by someone that knows how to unwrap the exceptions properly, or even has the capability to do so.

The real problem is that the WS/SOAP specs don’t allow for robust exception handling, and my understanding is that future versions of MS WebServices/WCF lets you express exception data as part of the service descriptor, which makes this whole ugly mess unnecessary :)

I sure have gotten far from the topic at hand. Back to smelly code! I may have to write a lengthier response later.

]]> By: jssingh http://lostechies.com/joeybeninghove/2007/10/29/talesfromthesmellyside-lt-code-gt-episode-1/#comment-70 jssingh Tue, 30 Oct 2007 02:52:30 +0000 /blogs/joeydotnet/archive/2007/10/29/talesfromthesmellyside-lt-code-gt-episode-1.aspx#comment-70 @Sean, one of the ways to present meaningful exceptions details to the clients of the web service is to embed the actual exception within SoapException (which is the exceotion that always gets thrown to the client). The client would basically iterate through the inner exceptions of the Soap Exception and take action accordingly. This explanation does not in any kind justify the mess created by an inexperienced programmer as Joey describes. That is utterly inexcusable. @Sean, one of the ways to present meaningful exceptions details to the clients of the web service is to embed the actual exception within SoapException (which is the exceotion that always gets thrown to the client).

The client would basically iterate through the inner exceptions of the Soap Exception and take action accordingly.

This explanation does not in any kind justify the mess created by an inexperienced programmer as Joey describes. That is utterly inexcusable.

]]> By: Sean Scally http://lostechies.com/joeybeninghove/2007/10/29/talesfromthesmellyside-lt-code-gt-episode-1/#comment-69 Sean Scally Tue, 30 Oct 2007 00:08:39 +0000 /blogs/joeydotnet/archive/2007/10/29/talesfromthesmellyside-lt-code-gt-episode-1.aspx#comment-69 Yeah, I have seen that second one from time to time. When it's out of ignorance I can forgive it, but when it's out of laziness I tend to wonder why that person is writing code. Yeah, I have seen that second one from time to time. When it’s out of ignorance I can forgive it, but when it’s out of laziness I tend to wonder why that person is writing code.

]]> By: Joe http://lostechies.com/joeybeninghove/2007/10/29/talesfromthesmellyside-lt-code-gt-episode-1/#comment-68 Joe Mon, 29 Oct 2007 23:17:56 +0000 /blogs/joeydotnet/archive/2007/10/29/talesfromthesmellyside-lt-code-gt-episode-1.aspx#comment-68 Heres the one that kills me, and makes me want to take a hammer to people's grubby little fingers: try { ... ... ... } catch(Exception e) { //empty block... } Heres the one that kills me, and makes me want to take a hammer to people’s grubby little fingers:

try
{
…
…
…
}
catch(Exception e)
{
//empty block…
}

]]> By: Joe Ocampo http://lostechies.com/joeybeninghove/2007/10/29/talesfromthesmellyside-lt-code-gt-episode-1/#comment-67 Joe Ocampo Mon, 29 Oct 2007 21:53:32 +0000 /blogs/joeydotnet/archive/2007/10/29/talesfromthesmellyside-lt-code-gt-episode-1.aspx#comment-67 I would still leave in the catch (Exception ex) { ... } and stack them, like so: try { ... } catch (SomeCustomException ex) { ... } catch (Exception ex) { ... } This way in case I missed an instance where the message is being thrown in won't break the existing behavior. You can then incrementally refactor towards your typed exception with out worry. You should be able to run a usage report on the class and proceed with refactoring accordingly. I am sure I am not telling you anything you didn't already know but this is for developers that are new to refactoring legacy code. I would still leave in the

catch (Exception ex)
{
…
}

and stack them, like so:

try
{
…
}
catch (SomeCustomException ex)
{
…
}
catch (Exception ex)
{
…
}

This way in case I missed an instance where the message is being thrown in won’t break the existing behavior. You can then incrementally refactor towards your typed exception with out worry.

You should be able to run a usage report on the class and proceed with refactoring accordingly. I am sure I am not telling you anything you didn’t already know but this is for developers that are new to refactoring legacy code.

]]> By: Sean Scally http://lostechies.com/joeybeninghove/2007/10/29/talesfromthesmellyside-lt-code-gt-episode-1/#comment-66 Sean Scally Mon, 29 Oct 2007 18:57:26 +0000 /blogs/joeydotnet/archive/2007/10/29/talesfromthesmellyside-lt-code-gt-episode-1.aspx#comment-66 I've seen this before in a situation that was not totally "wtf"-based. It was in code that was dealing with a web service. Legacy .NET 1.1 and 2.0 web services only can throw one kind of exception, so if you want to include any other sort of information to the client, you have to either use return values or sniff exception strings. I'm not saying that was the case here, or that even that particular situation forgives such a practice... :) I’ve seen this before in a situation that was not totally “wtf”-based. It was in code that was dealing with a web service. Legacy .NET 1.1 and 2.0 web services only can throw one kind of exception, so if you want to include any other sort of information to the client, you have to either use return values or sniff exception strings.

I’m not saying that was the case here, or that even that particular situation forgives such a practice… :)

]]>