This answer was posted in response to this question.
It's a little above my head right now, but is the "higher order function" supposed to be used within a client proxy class? Is this correct usage?:
public class MyProxy
{
readonly IMyService service =
new ChannelFactory<IMyService>("IMyService").CreateChannel();
public ResponseObject Foo(RequestObject request)
{
return UseService((IMyService service) =>
service.Bar(request));
}
T UseService<T>(Func<IIssueTrackerService, T> code)
{
bool error = true;
try
{
T result = code(issueTrackerChannel);
((IClientChannel)issueTrackerChannel).Close();
error = false;
return result;
}
finally
{
if (error)
{
((IClientChannel)issueTrackerChannel).Abort();
}
}
}
}
All I'm really looking for is some guidance here, and the correct way to do this.
This is actually not to bad. Perhaps you can cast to an ICommunicationObject instead, as the same code is required for your hosts as well.
The way to think about it is close is the friendly call. Please finish my call and return the proxy to the connection pool. Abort is "I don't care, shut the proxy because it's dead and also remove it from the pool because it's dead".
Depending on your code, you might want to abstract the "WCF Proxy" parts of the code from the function call parts if it's possible. That way you can unit test your application logic separately from the WCF proxy code.
You may want to look at a try {} catch (CommunicationException) so you can treat your WCF exceptions separately to an application level exception too, instead of the finally.
i.e
try
{
try
{
proxy.call();
//app logic
((ICommunicationObject)proxy).Close();
}
catch (SomeAppException)
{
//recover app exception
}
}
catch (CommunicationException)
{
((ICommunicationObject)proxy).Abort();
}
Related
Switch between production and test Webservice.
I have 2 version for the same WebService definition. Each version has its own database url etc.
MyLib.FooWebServicePROD.FooWebService _serviceProd;
MyLib.FooWebServiceTEST.FooWebService _serviceTest;
For now to siwtch form one to the other I used the Rename option in Visual Studio.
I would like to wrap all my instance and definition in a layer of abstration so the programe will not be edited everytime.
So I made mine singleton public sealed class FooBarWrap but with a huge amount a duplication like:
public bool Close()
{
if (_serviceProd != null)
{
_serviceProd.logout(guid);
log4N.Info("Closing PROD");
}
if (_serviceTest != null)
{
_serviceTest.logout(guid);
log4N.Info("Closing TEST");
}
return true;
}
public bool Login()
{
try
{
log4N.Info("Connection to FooBar webservice...");
if (isProd)
{
_serviceProd = new MyLib.FooWebServicePROD.FooWebService();
_serviceProd.Timeout = System.Threading.Timeout.Infinite;
_serviceProd.Logon(guid);
}
else {
_serviceTest = new MyLib.FooWebServiceTEST.FooWebService();
_serviceTest.Timeout = System.Threading.Timeout.Infinite;
_serviceTest.Logon(guid);
}
log4N.Info("done");
return true;
}
catch (Exception ex)
{
log4N.Info("failed !");
log4N.Error("Echec connexion au webservice FooBar", ex);
return false;
}
}
Is there a simplier way to achieve this? Without the client having a reference to one or the other web service, and without the heavy code duplication?
if (FooBarWrap.Instance.Login()){
//DoSomething
var ClientResult = FooBarWrap.Instance.SomeRequest()
}
Is there a simplier way to achieve this? Without the client having a reference to one or the other web service, and without the heavy code duplication?
It is.
You could simply use conditional dependency injection where depending on the environment you are or any other condition like host name, port number or url path, you would get different implementation of the service interface.
A simple conditional dependency injection that depending on condition provides one or the other implementation of the same interface.
kernel.Bind<ISomeService>().To<SomeService1>();
kernel.Bind<ISomeService>().To<SomeService2>().When(x => HttpContext.Current[host|port|url path] == "some value");
Ninject calls that kind of injection contextual binding
https://github.com/ninject/ninject/wiki/Contextual-Binding
I have asp.net application. All business logic in business layer.
Here is the example of the method
public void DoSomething()
{
PersonClass pc = new PersonClass();
pc.CreatePerson();
pc.AssignBasicTask();
pc.ChangePersonsStatus();
pc.CreateDefaultSettings();
}
what happens once in a while, one of the sub method can timeout, so as a result the process can be incompleted.
what I think in this case to make sure all steps completed properly is
public void DoSomething()
{
PersonClass pc = new PersonClass();
var error = null;
error = pc.CreatePerson();
if(error != timeout exception)
error = pc.AssignBasicTask();
else
return to step above
if(error != timeout exception)
error = pc.ChangePersonsStatus();
else
return to step above
if(error != timeout exception)
error = pc.CreateDefaultSettings();
else
return to step above
}
but it's just an idea, more then sure it's a proper way how to handle this.
Of course, this can be done more or less elegantly, with different options for timing out or giving up - but an easy way to achieve what you want, would be to define a retry method which keeps retrying an action until it succeeds:
public static class RetryUtility
{
public T RetryUntilSuccess<T>(Func<T> action)
{
while(true)
{
try
{
return action();
}
catch
{
// Swallowing exceptions is BAD, BAD, BAD. You should AT LEAST log it.
}
}
}
public void RetryUntilSuccess(Action action)
{
// Trick to allow a void method being passed in without duplicating the implementation.
RetryUntilSuccess(() => { action(); return true; });
}
}
Then do
RetryUtility.RetryUntilSuccess(() => pc.CreatePerson());
RetryUtility.RetryUntilSuccess(() => pc.AssignBasicTask());
RetryUtility.RetryUntilSuccess(() => pc.ChangePersonsStatus());
RetryUtility.RetryUntilSuccess(() => pc.CreateDefaultSettings());
I must urge you to think about what to do if the method keeps failing, you could be creating an infinite loop - perhaps it should give up after N retries or back off with exponentially raising retry time - you will need to define that, since we cannot know enough about your problem domain to decide that.
You have it pretty close to correct in your psuedo-code, and there a lot of ways to do this, but here is how I would do it:
PersonClass pc = new PersonClass();
while(true)
if(pc.CreatePerson())
break;
while(true)
if(pc.AssignBasicTask())
break;
This assumes that your methods return true to indicate success, false to indicate a timeoiut failure (and probably an exception for any other kind of failure). And while I didn't do it here, I would strongly recommend some sort of try counting to make sure it doesn't just loop forever and ever.
Use a TransactionScope for to make sure everything is executed as a unit. More info here: Implementing an Implicit Transaction using Transaction Scope
You should never retry a timed out operation infinitely, you may end up hanging the server or with an infinite loop or both. There should always be a threshold of how many retries is acceptable to attempt before quitting.
Sample:
using(TransactionScope scope = new TransactionScope())
{
try
{
// Your code here
// If no errors were thrown commit your transaction
scope.Complete();
}
catch
{
// Some error handling
}
}
There is plenty of information out there concerning WCF clients and the fact that you cannot simply rely on a using statement to dispose of the client. This is because the Close method can throw an exception (i.e. if the server hosting the service doesn't respond).
I've done my best to implement something that adheres to the numerous suggestions out there.
public void DoSomething()
{
MyServiceClient client = new MyServiceClient(); // from service reference
try
{
client.DoSomething();
}
finally
{
client.CloseProxy();
}
}
public static void CloseProxy(this ICommunicationObject proxy)
{
if (proxy == null)
return;
try
{
if (proxy.State != CommunicationState.Closed
&& proxy.State != CommunicationState.Faulted)
{
proxy.Close();
}
else
{
proxy.Abort();
}
}
catch (CommunicationException)
{
proxy.Abort();
}
catch (TimeoutException)
{
proxy.Abort();
}
catch
{
proxy.Abort();
throw;
}
}
This appears to be working as intended. However, when I run Code Analysis in Visual Studio 2010 I still get a CA2000 warning.
CA2000 : Microsoft.Reliability : In
method 'DoSomething()', call
System.IDisposable.Dispose on object
'client' before all references to it
are out of scope.
Is there something I can do to my code to get rid of the warning or should I use SuppressMessage to hide this warning once I am comfortable that I am doing everything possible to be sure the client is disposed of?
Related resources that I've found:
http://www.theroks.com/2011/03/04/wcf-dispose-problem-with-using-statement/
http://www.codeproject.com/Articles/151755/Correct-WCF-Client-Proxy-Closing.aspx
http://codeguru.earthweb.com/csharp/.net/net_general/tipstricks/article.php/c15941/
You could add a call to Dispose in your finally block, after the call to CloseProxy. At that point you can be reasonably sure that Dispose won't throw, although it seems a bit silly to add superfluous code just to keep code analysis happy - I'd probably just suppress the message.
(Whichever option you choose, include very clear comments explaining why the code does what it does.)
I have a question about handling exception. I have a Winform that uses a webservice proxy on each form for data retrieval and processing. Here is where I really got confused and having a long time deciding which is better.
A. For each call in the web service do a try catch to display the error message and allow the user to re try the process by clicking the button again.
B. Since the error occurred on the web-service and the error was probably because the web service was inaccessible, just make a generic try catch in the WinMain function in the Program.cs and show an error message that web service is inaccessible before the application closes.
The main argument in this is A is more user friendly but needs a lot of try catch code. B is easier to code but just lets the application ends. I am leaning on A but am trying to search the net with options how to lessen the code needed to be written to do this. Any ideas there?
When you add a web reference, the code generator automatically adds "Async" methods to access the web service.
I would recommend that you use the Async methods rather than the synchronous methods. The nice thing about that is that the EventArgs for the Async methods provide an Error property that you can use to see if the request was successful or not.
private void CheckWebservice(string data)
{
WebService.Server server = new WebService.server();
server.methodCompleted += server_methodCompleted;
server.methodAsync(data);
}
private void server_methodCompleted(object sender, methodCompletedEventArgs e)
{
if (e.Error != null)
if (MessageBox.Show("Error", "Error", MessageBoxButtons.AbortRetryIgore) == DialogResult.Retry)
{
// call method to retry
}
else
{
if (e.Result == "OK") { // Great! }
}
}
If you must use the synchronous methods for some reason, then you could, of course, write a class to encapsulate the methods to call your web service so that you can call it from various places without duplicating the code. Your encapsulation class could do all the error handling and return a result.
class CallWebService
{
public enum Result
{ Unknown, Success, NotAvailable, InvalidData } // etc
public Call(string data)
{
Webservice.Server server = new Webservice.Server();
string result = string.Empty;
try
{
result = server.getResult(data);
}
catch (Exception ex) // replace with appropriate exception class
{
return Result.NotAvailable;
}
if (result == "OK") return Result.Success
else return Result.InvalidData;
}
}
Encapsulate the webservice call and the try/catch block inside a class =)
I would like to use a COM object in my application.
How can I make sure the object is registered in the machine?
The only solution I found (also on SO) was to use a try-catch block around the initialization:
try {
Foo.Bar COM_oObject = new Foo.Bar();
} catch (Exception ee) {
// Something went wrong during init of COM object
}
Can I do it in any other way?
I feel its wrong to deal with an error by expecting it and reporting it, I would rather know I will fail and avoid it to begin with.
You are using exception handling the right way: to fail gracefully from a specific situation that you know how to recover from.
There's not a problem with using try-catch in this case, but you could at least catch more specifically : ComException.
"I feel its wrong to deal with an error by expecting it and reporting it"
Isn't it exactly the purpose of try-catch? BTW, an Exception occurs when something really bad has happened and since it is a pretty bad thing that the COM object you are referring to is not registered, therefore, an Exception is the perfect solution. And you can't handle an exception in any other way.
I think this is the right way to do it.
If you know your component's ProgId. You could try this trick
comType = Type.GetTypeFromProgID(progID,true/*throw on error*/);
If you're doing this a lot and wish you had a non-exception throwing equivalent, try:
public static class Catching<TException> where TException : Exception
{
public static bool Try<T>(Func<T> func, out T result)
{
try
{
result = func();
return true;
}
catch (TException x)
{
// log exception message (with call stacks
// and all InnerExceptions)
}
result = default(T);
return false;
}
public static T Try<T>(Func<T> func, T defaultValue)
{
T result;
if (Try(func, out result))
return result;
return defaultValue;
}
}
So now you can do this:
Foo.Bar newObj;
if (!Catching<ComException>.Try(() => new Foo.Bar(), out newObj))
{
// didn't work.
}
Or if you have a default object stored in defaultMyInterface you'd use to implement an interface if there's nothing better:
IMyInterface i = Catching<ComException>.Try(() => new Foo.Bar() as IMyInterface,
defaultMyInterface);
You can also do this, in a completely different scenario:
int queueSize = Catching<MyParsingException>
.Try(() => Parse(optionStr, "QueueSize"), 5);
If Parse throws a MyParsingException, queueSize will default to 5, otherwise the returned value from Parse is used (or any other exception will propagate normally, which is usually what you want with an unexpected exception).
This helps to avoid breaking up the flow of the code, and also centralises your logging policy.