In my application I am calling a web service.
try
{
theWebService.Method(parameter);
}
catch (Exception e)
{
//This catches and logs a SoapException
}
When I do this the a SoapException is caught and I'm only given a one line sentence on the issue. I'm assuming the SoapException is just relaying information from the actual exception that occurred in the web service (please correct me if I'm wrong about this). Does the web service log the full exception somewhere and if so where? Note that no additional logging has been added to the service besides what comes by default.
I'll assume you're still using legacy ASMX web services, and not WCF.
SoapException does not just relay the exception from the service. It can also be used to return a SOAP Fault message back to the caller.
By default, an unhandled exception in an ASMX web service will invoke ASP.NET Health Monitoring. By default, this will enter an event in the event log with details about the exception.
Related
Is there any possibility to throw an exception in the code of a web application which would not cause error 500 in the IIS logs?
500 means internal server error, i.e. your application have failed.
I'm guessing that you are asking for some sort of indication when the client have done something wrong.
For MVC 5.x there is an HttpException which can be used to return other error codes. (500 is returned for all exceptions but HttpException)
However! Exceptions are application failures. Your application does not fail just because the client sent something invalid.
Instead, you should send back a HttpResponse with the correct HTTP code. For MVC applications you can use the HttpStatusCodeResult in the controller.
I have a WCF service that handles errors by implementing an IErrorHandler and attaching it to the ChannelDispatcher's ErrorHandlers.
The IErrorHandler has a method called
bool HandleError(Exception error);
Which I implement and simply logs the exception to my DB.
My problem is that some exceptions occur before the web service's method gets called.
I also have a MessageInspector that I attach to the EndpointDispatcher that logs the soap messages.
Now, assuming I have an sql error and get an unhandled exception on my MessageInspector, the HandleError method gets called twice with the same sql connection error exception.
The problem is that it happens once when the connection's status is opened and once when the connection's status is closed.
Also, the second method on the IErrorHandler:
void ProvideFault(Exception error, MessageVersion version, ref Message fault);
doesn't get called, and then the framework wraps my exception with a FaultException, without letting me format it.
Is there any reason why the IErrorHandler behaves that way? Is there any other module I need to implement in order to handle unhandled exceptions that occur as part of the request's pipeline?
Why does the IErrorHandler get called when the connection is Closed?
We had a similar implementation of MessageInspector and wanted to know how long each request took. Consequently we did logging for both the incoming and outgoing messages. Perhaps this could be the case for your issue?
I'm not sure that the ProvideFault method is called when inside an extension behavior, however I was able to get it to fire from within the constructor of my restful WCF service. I think the 'workaround' of putting a try/catch in the inspector is a good approach.
Below are a couple of articles with implementation details on this topic:
IErrorHandler returning wrong message body when HTTP status code is 401 Unauthorized
How can I create custom XML namespace attributes when consuming a legacy SOAP service?
Also here is an article on how to do something similar in WebApi:
http://www.asp.net/web-api/overview/error-handling/web-api-global-error-handling
I have a try catch in my controller action method and if there is an error I would like to send the exception.message to the client using the proper method that implements IActionResult. How would I go about doing this?
You really only want to be catching exceptions in your try/catch that you can handle gracefully in the code. If a internal server error does occur, a 500 would be the appropriate response.
You should be validating the requests in order to prevent the 500 and when validation fails, then you can return the appropriate status code.
A very generic example might look like this in Web Api 2:
if (validationFailed)
{
return BadRequest("Your request failed because xyz..");
}
I have few webservices in my solution, they use NLOG for logging into the database, I want to catch the Request whenever there is an Exception , currently all the request and response calls are being logged into the database and I want to change it log only the Requests upon exception ..I did some research but did not find any proper answer, if you could give me some example than it could be verymuch helpful
I think you should try Application_Error method in Global.asax. It can catch any unhandled exceptions of application.
Documentation here: http://msdn.microsoft.com/ru-ru/library/24395wz3%28v=vs.100%29.aspx
A few days ago I asked a very similar question. I was about returning values/errors inside the application. I accept an answer to not return error as and object but throw an custom exceptions.
Now, I'm not exactly sure how to deal with it using WCF services. I wish the service will be as simple as it could be for client.
Speaking very generally, my project looks like that:
Client -> WCF Service application -> Database.
Inside WCF app I've got my own exception class, and it works fine. But let's say client want sth from db. My question is:
What should I return to the client outside my app?
A. Complex type: A value with meta data (information about a possible error[1]). And when really unexpected error occurs throw an exception.
B. Just a value (when possible error occurs - throw an exception)
[1] - invalid string format, can't connect to database or sth like that. I mean - If I know what the error exactly is - why throw an exception to client - I'm not sure about that.
The decision how to tackle this problem depends on the client. If you have to support Silverlight Clients, throwing exceptions is out of the picture because Silverlight Clients using the browser HTTP Stack cannot deal with them. For Silverlight Clients I generally recommend (and use myself) the approach described here.
By design, WCF hides exceptions from the client. It's up to the developer to determine what, if any, information is returned to the client when an exception occurs.
I would look at using FaultContract or FaultContract<T>, and return exceptions that you wish to via that mechanism.
Here's some articles to look at:
Fault Contract
WCF Tutorial Fault Contract
You might also want to look at IErrorHandler for WCF:
IErrorHandler Interface