How to handle the WCF fault exception in Silverlight 3.0 .Any in built object model support for fault exception handling?
Since all your calls to your web service will be async. The service reference to your WCF project will automatically create "completed" events for you on the client when the async call has been completed.
These events always contain a "Result" property and an "Exception" property. Once the exception is handled you can do what you want with it.
Is this what you mean?
Try this:
http://www.codeproject.com/KB/silverlight/SilverlightExceptions.aspx
You're right that SOAP faults are not supported, this technique wraps them on the server side then unwraps them on the client so you can handle them neatly.
Related
Is there anyway to handle exceptions which are thrown in Hub constructor methods?
Currently there is only HubPipelineModule which can handles only calling methods related exceptions but not constructor exception.
Assume in Hub constructor I get the "Database connection error". Now I want to show the end user a proper message.
I checked the following links but they are not helpful in this case :
SignalR exception logging?
SignalR, Owin and exception handling
Your best bet for handling exceptions thrown from a Hub constructor is probably by providing your own IHubActivator.
Here is an example of how you can replace SignalR's IHubActivator. In that example the purpose for replacing IHubActivator was to use Simple Injector to activate hubs, but the same principle applies if you just want to handle/log any exceptions thrown during Hub construction.
Validation can happen on client side and server side, what if it happens on db side, if I want to stop an insert/update by rollback in trigger, how do I notify the client side, now it seems breezejs just ignore my error raised in trigger.
If you are using an Entity Framework or NHibernate backed server, then throwing any exception on the server should fail the entire transaction and turn into a failed save on the client ( with all changes placed back into their 'presave' state). In order for this to occur the Breeze server must detect an exception. You may need to have your trigger to raise an exception.
If you are using some other server, the behavior depends on whether the database supports tranactional semantics. ( for example MongoDB does not).
Found it does return, just need set severity to higher and parse error message from http data.
I have a web application with the following layers:
Client(s)
WebAPI
Services
Repository
Core
I'm not sure where to put error handling though. Within the webAPI controllers, should I just have try/catch statements? Is it ok to throw errors in the services/repository code? I'm trying to avoid passing any data to the client, other than some friendly error message.
Business errors should be handled in your service layer (for example things like username already exists). Putting try/catch statements in all your controller actions could quickly become cumbersome and lead to repetitive code. You may take a look at the custom error handling article which provides examples of handling various errors in the Web API such as custom error filters (deriving from the ExceptionFilterAttribute class and overriding the OnException method).
You can create a custom exception type that would be intercepted by an ExceptionFilter or http module. It would set the HTTP status code and description. Optionally, it can also return a serialized object with the error data.
Other exception types would return status code 500.
Scenario: Site uses Mvc async controller.
Error: Everytime an async end operation (like EndReceive) throws an error it also crashes IIS.
This is the type of error one should always try to catch but is the default behavior otherwise always crashing the IIS process? (don't know if i should leave it or start more in depth troubleshooting)
Thanx,
I think you will find the following blog post useful in understanding what happens under the covers.
I am developing some SOAP web services using Ruby on Rails and considering how to handle generic failures. These generic errors are applicable to all the methods within the service and include the following :-
Missing Request element
Missing Authentication element (Custom)
Invalid Authentication details
I can intercept these errors within my controller before calling the relevant method and respond appropriately. My question is which implementation is easiest to manage from a Client perspective. My options for handling these errors seem to be as follows.
Raise an exception and let the SOAP service generate a SoapFault. This would be fine except I have little (no) control over the structure of the message contained within the SOAP fault.
Return an Http 400 response with an agreed data structure to indicate the error message. This structure would not be defined within the WSDL though.
Include a Status element in all responses, whether successful or not and have that status element include a code and an array of error data (Including error messages).
Option three seems like the best solution but is also the most error prone to implement as the implementation of web services in ROR precludes me from implementing this in a generic way and each method becomes responsible for checking the result of the checks and rendering an appropriate response. Admittedly this would be a single function call and return on failure but it is relying on the developer to remember to do this as we add more options.
I appreciate that most ROR developers will say that this should be implemented as a REST service and I agree, in fact we already have REST services to do this but the spread of SOAP in the corporate world, and its impressive tooling support means that we have to provide SOAP services to remain competitive.
In your experience what would be the easiest implementation for clients to handle and does this differ dependant upon the libraries/language of the client process.
A SoapFault would be the preferred way to signify errors. SoapFaults can contain additional information in their <detail> element.
The advantage of a SoapFault over some status element is that the caller can use standard exception handling, instead of checking for some status field.