Introduce RequestNotSupportedException
#2704
Conversation
MarcoRossignoli
added
the
Area: Testing Platform
|
cc: @Evangelink |
|
|
||
| namespace Microsoft.Testing.Platform.Requests; | ||
|
|
||
| [Serializable] |
There was a problem hiding this comment.
I think we should avoid this one based on docs updates: dotnet/docs#34893
| namespace Microsoft.Testing.Platform.Requests; | ||
|
|
||
| [Serializable] | ||
| public class RequestNotSupportedException : Exception |
There was a problem hiding this comment.
Shall we have the usual ctors? Message and inner exception?
There was a problem hiding this comment.
I was wondering if make sense...the platform doesn't needs any message, I think we will take the exception and we will do something like
- print in console
- crash
- move on if we're good with it...
So I wonder what the test framework author could put in that message.
But I won't oppose if you want it to "standardize" or have some inheritance in future, it's not sealed atm.
There was a problem hiding this comment.
No you are right, we won't do anything about it.
There was a problem hiding this comment.
I have been checking the code and I think we did a fail on our design and we should have had a return to the ExecuteRequest api https://github.com/microsoft/testfx/blob/main/src/Platform/Microsoft.Testing.Platform/TestFramework/ITestFramework.cs#L21
Discussed a bit off line, fine to me if we want to use NotSupportedException but I would not change the return value of the api, the only 2 scenario come to my mind to return prematurely from this method is for a unhandled exception or missing request support. |
|
Close as not needed atm, we can use |
This exception should be used by the test framework author in case of unknown request.
@Evangelink feel free to refactor as you want. As soon as will be merged I'll it to the documentation.
This allow to evolve the testing platform with new request without side effect, for instance if we want to know the total amount of tests the will run introducing in future a
CountTestsRequestto have a better interface(progress bar) we can add it and in case ofRequestNotSupportedExceptionexception we simply bail out that feature.This doesn't mean that capabilities won't be used for this reason, but recognize if the adapter supports or not a request is useful to try to carry on the test session to the end "if possible".