I'm developing a silverlight application that consumes a webservice. Calls to this webservice are made Asynchronously. But when an exception occurs during a procedure of the async call, I get an error on the completed event but i lost my original exceptions information. Independent of what the original exception was, I always get "The remote server returned an error: NotFound" back, with stack that points to "external" code.
Any advice?
When the service throws an exception it's translated to a 40(x) HTTP response that gets handled by the browser before the Silverlight plugin can handle it. To avoid this, wrap your WCF calls in a try/catch block and send exception data back to the client through an HTTP response that can be handled by Silverlight, such as 200. Here's a terrific implementation of this strategy on codeproject:
http://www.codeproject.com/KB/silverlight/SilverlightExceptions.aspx
This happens with any exception in your SL to WCF, sometimes you can find the innerexception with Fiddler2 in the transfered data or you might see the HTTP error code which can give you a hint , other times it's harder to find. This is my big request item for SL 4.0, better WCF debugging.
http://www.fiddler2.com
Follow James Cadd's advice above. Getting more informative error messages will certainly help and, unfortunately, you can't rely on the debugger to generate them for you.
Even if you're not a big fan of unit testing, this is a place where it's more than worthwhile. Constructing a set of tests that will purposefully send your webservice bad data and making sure that you get back informative errors will help set you up to figure out why it's not working with the Silverlight app. Writing these kinds of tests takes a different way of thinking, but it will give you a lot of confidence in your code if you know that you've tried to break the webservice in every possible way and it always gives you back something you can use to trace the problem.
Related
Some requests silently fail in my python app, intermittently and unpredictably. The hallmarks of the failure are:
Request returns a 200, so the client doesn't know there's a problem.
Request does NOT successfully execute on the server.
No logging statements are recorded for the request.
Below is an example from my logs of a bunch of requests which are each supposed to write an entity to the datastore. You can see for the lower, successful request, a blue 'i' is present, indicating that info level logs were recorded. When I examine the datastore, an entity was successfully written for this request.
However, for the failed request, you can see there is just a white box, and there are no logging statements present at all. While the server returned a 200, no entity was written to the datastore for this request.
Has anyone encountered something like this before on App Engine? Any ideas on how to debug it? I've seen it in multiple different apps myself, but I've never been able to figure it out.
EDIT
To clarify, the main problem here is that code doesn't execute, as measured by the failure to write an entity. The spurious 200 and lack of logging is an associated symptom.
From a comment originally, but seems to be the resolution path for this issue:
Given that there are no log statements at all in the line and you appear to unpack the arguments and log them as soon as you enter the handler, this starts to look like an infrastructure/platform issue.
In such a case, it's best to open a public issue tracker issue, with "Type-Production" as a tag, including your app's app id and a timeframe, and as much information about your app and request handler involved as possible, and platform support will pick up the issue in the course of triage.
That said, it's worth examining the handler to make absolutely sure there's no way you could be exiting from the handler and sending a 200 without logging anything or seeing an exception. It all depends on what the code handling the request is capable of, what stack of libraries it's build upon, etc.
I have recently shown to my team leader the ElmahR Dashboard and now he wants to implement ExceptionsLog with ElmahR in all of our current projects, including those that are Winform Applications, and after many days of searching I can't find a way to add a Winform Application as "ElmahR source".
Does anyone have a clue?
ErrorPostModule in ElmahR.Elmah does not support Winforms apps because it's been written to be an ELMAH module, so it's tied to an ASP.NET lifecycle and cannot be easily adapted. That said, ErrorPostModule does not do anything so magic and can be easily taken as a guideline to write a small "handler" to be used in a Winforms app. Take a look at its code here, what you should do is:
replace what's in the OnInit method, which simply reads configuration bits and attaches the error handler
when an error occurs, handle it like it's done in the SetError method to post it to the right destination reading the configuration parameters you read before. You would reference ELMAH and create an Error instance from your exception, and then use ErrorJson.EncodeString to encode it
You may want to borrow the W3.cs file to simplify the http form compilation.
At some point I might generalize this work and put it in ElmahR.Elmah, but not sure when I'll be able to do it.
I just forked the elmahr source code to work on this, I want to post errors from console applications, so I'm going to remove the dependency on Elmah and create the "error" objects and send them to the dashboard.
It's a work in progress but can be used as starting point for solving your problem.
https://bitbucket.org/rudygt/elmahr
Update: the fork now include full support to post to ElmahR using a ServiceStack endpoint, using json over http. This remove the dependency over the original Elmah to publish errors to the dashboard. The first example is a C# Console Application
Hello All,
I would like to know how to handle the exception in the Silverlight
? Since it is the code which runs
at Client side , So if some
exception happens in the client nor related to web service . So should I show
user friendly message and again make a
call to the server and store the exception details there.
Is it the correct approach ? If not
please suggest a better one
Regards,
Phani
The standard seems to be to expose a method in your webservice (such as logEvent(exception ex)) and handle it the same way you would any other .NET error.
The Silverlight Integration Pack for Enterprise Library apparently provides for a lot more support for error logging too, so that may be worth a look, though I haven't used it myself.
I know this is a hot topic on StackOverflow, but do bear with me.
We have a Silverlight 3 application talking to a WCF service. Every now and then, calls to the WCF service return a NotFound exception.
I've read pretty much every post on SO and Google on this subject but I can't figure out what's going wrong. Here are some of my findings:
The exception happens on random calls and at random moments. Sometimes a method will work for 50 times and suddently it bugs out. I have a feeling it's related to a timeout, since it's most reproducable if I let the application idle for a while before invoking a call, but this is not always the case - sometimes the one of the first calls in the application fails.
We use the SilverlightFaultBehavior to convert the HTTP error code to 200 and we have plenty of instances where throwing an exception on the serverside actually bubbles up to the client side, so I can confirm this should be working as expected.
Fiddler shows nothing special at the moment the exception occurs. I don't even see the call in question. This worries me, but it might mean that the exception is a result of a call that happened minutes ago and timed out?
Service Trace Viewer shows nothing.
I attach Visual Studio to to Silverlight project and to the WCF services project, set debugging to break on all exceptions (thrown or handled) and it doesn't break (except in Silverlight to tell me about the NotFound problem). This causes me to think that maybe the NotFound is not in response to an exception on the WCF service side?
I really have no idea where to go from here. Any help at all, any pointers or ideas of things to try are welcome.
Here are some thoughts for the points you mentioned:
1) The exception happens on random calls and at random moments - Make sure the data being sent as a return value of method is valid. I had a case when sending an object with some empty properties caused a failure in serialization. I found this out using IIS logs/ Service Trace Logs.
2) So, did you find anything useful?
3) I don't think fiddler can help with this kind of an error.
4) Are you sure about this? Did you set up Trace Logs correctly?
5) You won't find any exceptions that can help you here. The actual exception (when you see 'Not Found' error) is raised while wrapping the message/data from server side or unwrapping message/data on client side.
So, to summarize make sure the data is in correct format (may seem to be correct for you but not WCF, just play with it for a while with different values) and verify the Trace Logging again.
What is a binding of the service? Where is it hosted: IIS or VS Deployment server?
I have seen this problem recently, something was wrong with IIS. It couldn't even open *.svc files.
So here is a plan of activities:
Try to open svc file using http address like http://localhost/MyApp/MyService.svc
If it opens, write a console application and test the service.
If it works, write a silverlight simple application.
I hope this will help.
I fixed this by adding
minFreeMemoryPercentageToActivateService="1"
to Web.config. By default it is
minFreeMemoryPercentageToActivateService="5"
which sometime causes this error.
We have exception catching code in most of our event handlers etc, this leads to very complex logic, with flags that are set to say if there has been an exception so as not do the next step etc.
At first sight I would move all exception report/logging to the AppDomain.UnhandledException event, however from my experience with WinForms this will lead to a lot of exceptions being lost.
Also when there is an exception we have include details of the operation the user was trying to do in the log message.
So what are people experiences both bad and good at exception logging/reporting/recovering in WCF applications?
(I would love to say that we had something like the Model-View ViewModel (MVVM) pattern) in use, but we don’t and are a long way from being able to use any “clean” design like that)
Its not specific to WPF, but the best place to handle exceptions is to handle them at the point where user interaction with the form is converted into a logic process. This is either in the codebehind or in a controller method.
Only at this level do you know what the user is trying to do and what reasonable steps to take when an exceptional situation is encountered.
Of course, if you don't know what exceptions may be thrown don't try to handle them. And don't bother handling exceptions that you can't do anything about.
You should never have to use flags to say exceptions have been handled - that smells like bad design.
Exceptions fall into two categories:
expected (e.g. validation failed, data could not be put into database)
unexpected
your expected ones should be handled pretty quickly, and logged depending on the type of exception. For instance, if the user entered some data that was rejected by validation code in the business layer, i would catch the exception and notify the user, but not log it - because it was expected and i can deal with it. Others could be "expected", but you cannot deal with it - like a WCF call failed due to timeout or oversized data packet. This you should definately log - you may even be able to recover from it, so once again it should be caught and dealt with. Note the lack of flags - an exception is either dealt with, or it continues to bubble up. If you need to take an action you can do so, and then rethrow the exception to let it bubble up further - look, still no flags :)
Another approach i have taken in the past when throwing (custom) expected exceptions in an ASP.NET application is to mark it as being capable of being handled locally or not. This means that when the aspx caught the error (generic error handler in a base page that all apsx's inherited from), then it knew whether it should just show it locally within the page (after doing a text lookup in a resource file), or whether it should redirect to an error page. This approach was especially useful when doing a mixture of standard postbacks and ajax callbacks (may not be particularly useful to WPF apps though).
For major unexpected errors, you can catch those at the Application level, here is a previous SO post about it. Another two related posts that might be useful here, and here.
Another thing i should mention is to make sure your error logging is relatively bulletproof - there is nothing worse than your exception logging process throwing an exception, and losing all the valuable details of that tricky bug you are trying to track down for that irate user.