-
Notifications
You must be signed in to change notification settings - Fork 505
Exceptions #19
Comments
What if you use the system exceptions as the base types:
The benefit of this is that it allows for some "typical" usage as well as using what the user already knows: try {
var result = await api.DoSomethingAsync();
} catch (NotSupportedException) {
ShowAlert("This device does not do that.");
} There is no need to force the user to use the custom exceptions, when the base, existing exception may cover more cases in one. |
Yes! |
I think we also need to investigate the name of the exceptions: |
We might use capability prefix for that exceptions: |
@jamesmontemagno @Redth we need to properly decide what exceptions we throw in cases, and when we just do nothing. We currently have different ways of indicating that nothing can be done:
One case where we do nothing is in Android's energy saver API: if we are not Lollipop, then we just fall through: One case where we throw One case (and the only case so far) where we throw So far, I was able to determine that we throw
We throw a
We throw a
We do "nothing":
|
I am currently working on #178 where a variety of things can go wrong depending on the Platform. I would love to have a general PlatformException or similar to be able to throw a consistent Exception across Platforms with a corresponding inner exception for certain failures. This may be due to exceeding the recording limit on uwp or the failure to set a category for an iOS audio stream. I would love some input into what exception throwing strategy to follow there. |
There are some patterns in several API's that we might want to have some common exception types for.
Feature Availability
Things like GPS, Cameras, Phone, SMS, etc are not always available on a given device. When a method is called which tries to make use of such a device, we should throw a consistent exception to let the developer know the feature is unsupported on the current device:
NotSupportedOnDeviceException : NotSupportedException
There may also be the case where a feature is technically supported by the device, but not enabled:
NotEnabledOnDeviceException : InvalidOperationException
Open to ideas on naming, and other common exceptions we may require...
The text was updated successfully, but these errors were encountered: