Hi, I have subscribed to appHost.ServiceExceptionHandlers , appHost.UncaughtExceptionHandlers and public override void OnExceptionTypeFilter …
However there are situations where none of these methods are called ,
Specifically , if I have a service that requires an integer as input and, as a rest request , a letter is passed ,
@sabbadin12 Would you be able to provide a small project that reproduces the problem? This would make it a lot quicker to track down what might be causing this problem for you.
Actually same use case using soap format will not pass through
either.
In other word, if the soap message contains a property that should be an integer and you pass a string as xml element value a string, the UncaughtExceptionHandlers will not be called and a generic 500 exception will be retunerd in text/html with a generic description “Input string was not in a correct format.” Stack Trace says:
[SerializationException: DeserializeDataContract: Error converting type: DeserializeDataContract: Error converting type: There was an error deserializing the object of type Geographic.Http.Services.CastError. Content cannot be converted to the type Int. Line 1, position 151.]
ServiceStack.Serialization.DataContractSerializer.DeserializeFromString(String xml, Type type) +167
ServiceStack.Host.Handlers.SoapHandler.ExecuteMessage(Message message, RequestAttributes requestAttributes, IRequest httpReq, IResponse httpRes) +1037
The point is: why the UncaughtExceptionHandlers has not been called while same use case for json format will be?
on the swagger page you can call http://localhost:56440/hello2/abc
and you break into UncaughtExceptionHandler …
but if you pass http://localhost:56440/hello2/-23 (there is a validator that requires the number be < -1 … )
you wont’ break in any error handler , and not even in the globalresponsefilter , only the onendrequest is hit …
what we are trying to achieve is
hooks to log any kind of errors in the service (but the 404)
put a customized mesage in the ResponseStatus.Message in all error cases
thank you ,
two more things :
a) it seems that Onendrequest is not called for soap calls
b) it would be nice to have a appHost.EndRequest.Add(…); instead of having to override Onendrequest
Now UncaughtExceptionHandlers will be called for soap call as well, but only if the issue occurs on the input side (as per sample case pointed out here above).
In case the issue occurs on the output side, UncaughtExceptionHandlers will not be called and a generic html output will be returned including the stack trace
[SerializationException: Member RequiredProperty in type ResponseCustomizerSoapOutputDeserializationExceptionResponse cannot be serialized. This exception is usually caused by trying to use a null value where a null value is not allowed. The 'RequiredProperty' member is set to its default value (usually null or zero). The member's EmitDefault setting is 'false', indicating that the member should not be serialized. However, the member's IsRequired setting is 'true', indicating that it must be serialized. This conflict cannot be resolved. Consider setting 'RequiredProperty' to a non-default value. Alternatively, you can change the EmitDefaultValue property on the DataMemberAttribute attribute to true, or changing the IsRequired property to false.]
//ServiceModel
[DataContract(Namespace = Constants.SVC_NS)]
public class ResponseCustomizerSoapOutputDeserializationException
{
}
[DataContract(Namespace = Constants.SVC_NS)]
public class ResponseCustomizerSoapOutputDeserializationExceptionResponse
{
[DataMember(EmitDefaultValue = false, IsRequired = true)]
public string RequiredProperty { get; set; }
}
//ServiceInterface
public object Any(ResponseCustomizerSoapOutputDeserializationException request)
{
return new ResponseCustomizerSoapOutputDeserializationExceptionResponse();
}
Hi Demmis,
Thanks for your quik reply/fix, but IMHO now is even worst:
The hook will be now called after OnEndRequest, so I’m not able to customize the response and now, if I do not handle it, my serialization error on the output side disappear, if I do handle it,I’m not able to distinguish between normal service exception and serialization exception.
Why you decide to handle it as UncaughtExceptionHandlers instead of UncaughtExceptionHandlers?
IMHO should be handled as an UncaughtExceptionHandlers: serialization issue should be always treat in the same way no matter if the error occurs during the input o during the output.
Said so, please make the output serialization exception handled as UncaughtExceptionHandlers and fire it before OnEndRequest or rollback to previous implementation.
Since we know the Service that’s executed it fires the IAppHost.ServiceExceptionHandlers but it’s now been modified it so OnEndRequest() is called after the handlers. This change is available on MyGet.
If you prefer you can modify it to call UncaughtExceptionHandlers by overriding IAppHost.WriteSoapMessage, e.g:
Hi,
now ServiceExceptionHandlers has been called before OnEndRequest, but still I’m not able to distinguish between exception occured within the service method or outside such as serialization during the output.
An other issue with this new changes is the retuned object from the ServiceExceptionHandler will not be written in the output, but the previous one will be (the one created before the serialization error raised)
the override you proposed has 2 issue: a minor one
HostContext.CompleteRequest(req);
is internal. So I tried to call it via reflection
the major one is the output contains “2 outputs”: the original one before the serialization error occurs + the custom one I create through the custom uncaughtException handler. In short the response buffer has not been clean it out.My uncaughtExceptionHandler implementation down below (based on \src\ServiceStack\HttpResponseExtensionsInternal.cs)
private void uncaughtExceptionHandler(IRequest req, IResponse res, string operationName, Exception ex)
{
//my output customization
var errorDto = createResponseStatusForUncaughtException(operationName, ex);
var httpReq = req;
var httpRes = res;
var contentType = httpReq.ResponseContentType;
var statusCode = (int) HttpStatusCode.InternalServerError;
if (httpRes.ContentType == null || httpRes.ContentType == MimeTypes.Html)
{
httpRes.ContentType = contentType;
}
if (HostContext.Config.AppendUtf8CharsetOnContentTypes.Contains(contentType))
{
httpRes.ContentType += ContentFormat.Utf8Suffix;
}
//TODO VERIFY IF StatusDescription EVER USED in the response to the client
if (httpRes.StatusDescription == null || httpRes.StatusDescription == "OK")
{
string statusDescription = (((dynamic) errorDto).Message).ToString();
// if string is longer than 512 .net raises an exception
httpRes.StatusDescription = statusDescription.Truncate(509) + "...";
}
httpRes.StatusCode = statusCode;
ResponseSerializerDelegate serializer = null;
if (contentType == "application/soap+xml")
{
// custom serializer to avoid an exception due to missing SoapMessage within the request in case of not-serializable input
serializer = SerializeSoap12ToStream;
}
else
{
serializer = HostContext.ContentTypes.GetResponseSerializer(contentType);
}
if (serializer != null)
{
serializer(httpReq, errorDto, httpRes);
}
httpRes.EndHttpHandlerRequest(skipHeaders: true);
}
Instead of HostContext.CompleteRequest() you can call OnEndRequest() directly.
The ResponseBuffer could be dirty at this point so I’ve avoided writing the response but have changed it in this commit to write it if the ResponseStream is reset-able, i.e. if it’s using a BufferedStream. The test also shows it uses a buffered output stream for SoapDeserializationException requests, e.g:
if (dto is SoapDeserializationException)
req.Response.UseBufferedStream = true;
You can determine when the exception was thrown by setting a flag in IRequest.Items, e.g:
Tomorrow at work I’ll try the new build.
Not sure I understood the strategy to make an assumption on a specific dto: serialization issue may occur on any dto.
The goal is to return a custom dto in case that serialization error occured, not necessary the one related to the request, same as per uncaught exception handler since the proper response dto is not serializable at that time/during that specific request.
There’s no strategy or assumption, it’s making it implicit which test requires a buffered response so any non-default configuration is limited to just the tests that need it.
You can look at req.Response.Dto != null which will be populated with the Service’s response to determine if the Service executed successfully.