"Chad" <chad@abc.com> wrote in message
news:ba1fde123953a8c98d8155a0f0d1@news.microsoft.com...
> Hello ged@nospam.here,
>
> From the sounds of it we will have the same problem then. So we'll always
> have to do :
> try
> {
> doSomething();
> }
> catch(Exception ex)
> {
> if(N-Tier Mode)
> {
> LogError(blah);
> throw new ServerException("Sorry dude the server wasn't able to
> process...... ");
> }
> else
> throw;
> }
>
> Can this really be the only way? Please someone, tell me there's an easier
> way than introducing all this clutter.
>
> Cheers,
>
>
>
>> AFAIK, WCF applies the remoting steps regardless of the location of
>> the
>> client or the server. i.e. same machine or across a LAN/WAN.
>> So, no need for you to detect which way you are using your object, it
>> will
>> always be the same.
>> Think of it ALWAYS being across machine boundaries and WCF will handle
>> the rest for you.
>>
>> Does that make sense ?
>>
>> "chad" <chad@abc.com> wrote in message
>> news:ba1fde12394ae8c98d6f91a68fc1@news.microsoft.com...
>>
>>> Hello Bram,
>>>
>>> Thanks for the reply.... eek, that's what we were afraid of.
>>>
>>> We're using the objects in a non-remoting as well as a remoting
>>> environment. So like you mentioned it's a completely seamless
>>> approach with the big drawback of server errors in the remoted
>>> environment being propagated back to the client. I would hate to
>>> clutter the code with wrappers but it seems like it's the only way.
>>>
>>> The whole concept seems so simple and it's hard to believe there's no
>>> hook inside the remoting layer that we can use for processing before
>>> information is sent back to the client.
>>>
>>> Anyone aware if WCF has an elegant solution to overcome this problem?
>>>
>>> Regards,
>>>
>>>> Hi Chad,
>>>>
>>>> The beauty of .NET remoting is that it's almost entirely
>>>> transparent. Once you have a remoted object, you can use it like a
>>>> local object. However, the drawback in your case is that it's almost
>>>> entirely transparent. So in your case, the best thing you can
>>>> probably do is create a wrapper method that catches the relevant
>>>> exceptions (or all exceptions, if you are feling lucky) like this:
>>>>
>>>> [Serializable()]
>>>> public class MyClass : MarshallByReferenceObject {
>>>> public void MyMethod() {
>>>> // Do stuff that might generate an exception
>>>> // ....
>>>> // ....
>>>> }
>>>> public void MyMethodWrapper() {
>>>> try {
>>>> MyMethod();
>>>> }
>>>> catch(ArgumentException) {
>>>> // Do nothing, just catch exception
>>>> }
>>>> }
>>>> }
>>>> The pitfall, of course is: There is a reason these exceptions are
>>>> thrown. Your application state probably won't be what you think it
>>>> is.
>>>> So you might consider catching the exceptions on the client side and
>>>> react appropriately.
>>>> Regards
>>>> Bram
>>>> On 13 jun, 09:26, chad <c...@abc.com> wrote:
>>>>> Hi,
>>>>>
>>>>> We have some services that we start up using
>>>>> RemotingServices.Marshall(..).
>>>>> We need to filter exceptions generated on the server before they
>>>>> get
>>>>> serialized
>>>>> and marshaled to clients. Where can we hook into those exceptions
>>>>> so
>>>>> we can
>>>>> decide whether to pass a new friendly exception or the actual
>>>>> exception that
>>>>> occurred.
>>>>> Thanks,
>
>