The following forum(s) have migrated to Microsoft Q&A (Preview): Developing Universal Windows apps!
Visit Microsoft Q&A (Preview) to post new questions.

Learn More

 locked
Exceptions thrown from HTTP filter do not contain the correct message RRS feed

  • Question

  • I have a HTTP filter implemented using IHttpFilter which I throw some IOException's from with custom messages. However when the exceptions are caught by the method which awaits the SendRequestAsync of HttpClient the IOException's just return the generic message "An I/O error occurred".

    Any ideas why the messages in the exception are not being returned correctly and instead I'm just getting the generic exception message? I also tried this with a different exception (CrytpographicException) and found the same issue was happening.

    This is in a Windows Phone 8.1 Silverlight app.

    Tuesday, March 3, 2015 5:23 AM

All replies

  • I've also noticed that if I throw a custom exception the code awaiting the call actually receives an exception of type Exception with no message.

    The debug output shows the following:

    A first chance exception of type 'Okta.Verify.Utilities.InvalidHttpRequestException' occurred in Okta.Verify.Utilities.DLL

    A first chance exception of type 'Okta.Verify.Utilities.InvalidHttpRequestException' occurred in mscorlib.ni.dll

    'AgHost.exe' (CoreCLR: Silverlight AppDomain): Loaded 'C:\windows\system32\en-US\mscorlib.debug.resources.dll'. Module was built without symbols.

    A first chance exception of type 'System.Exception' occurred in mscorlib.ni.dll

    and the stack trace of the received exception is:

    System.Exception: Exception of type 'System.Exception' was thrown.\r\n   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)\r\n   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)\r\n   at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()\r\n   at Okta.Verify.Utilities.NetworkingClient.<SendRequestWithJsonResponseAsync>d__8`1.MoveNext()

    and the inner exception is null

    Any ideas what is happening and how I can fix it so that the awaiting method receives the actual correct exception type 

    Tuesday, March 3, 2015 6:31 PM
  • I have similar exception but someone told me we don't need care about first chance because its system level error, after some investigating I found we can catch the exception on vs by some setting, I modified the exception setting and was able to see the co exception.

    Wednesday, March 4, 2015 2:02 PM
  • Do you remember what setting you changed?
    Wednesday, March 4, 2015 6:41 PM
  • Anyone got any ideas about this issue?
    Thursday, March 26, 2015 7:15 PM