It was always a good practice not to catch and not to throw common System.Exception and if you catch System.Exception, rethrow it using the throw keyword. So in .NET Framework we always can open a method description and find out what it can throw: msdn.microsoft.com/en-us/library/fkbhht5w(v=vs.110).aspx That is clear for me and if anybody wants to discuss it or to argue– you are welcome. But in UWP/WinRT, please, take a look at Capture photos and video with MediaCapture, There is a code:
try
{
await _mediaCapture.InitializeAsync(mediaInitSettings);
_isInitialized = true;
}
...
catch (Exception ex)
{
Debug.WriteLine("Exception when initializing MediaCapture with {0}: {1}", cameraDevice.Id, ex.ToString());
}
It was strange for me to see such thing in official documentation, but, then I found out that a lot of UWP/WinRT methods can throw an exception of type System.Exception. And as I understand it’s so because UWP errors are reflected to System.Exception in C# . As I see, a lot of issues are hidden in that catch(Exception). For example, OutOfMemory will be recognized as camera initializing problem. And since we use “await” keyword a lot of exceptions from “Task” mechanism will be hidden as well. Furthermore, passing MCSD (universal apps) tests I saw a question about exception catching and “proper” answer was to catch every exception. And there was no one word about Application.UnhandledException and UnobservedException.
Finally, my questions are:
- Why UWP reflects errors to common System.Exception but not to ComException, for example, to follow c#/.NET best practices?
- Why UWP documentation does not cover Exceptions and HResult values for every method as it is in .NET Framework?
- MSDN example writers just don’t understand that it hides issues and brings new, or it’s just a new .NET potilic?