Handle unparseable UniqueID consistently

[jlink]

Discovering tests via UniqueIdSelector and a string-based unique ID that cannot be parsed by UniqueId.parse() is handled differently by each engine. Should be handled consistently in the launcher.

I see several options:

• Throw (subtype of) JUnitException when executing the request or when creating the selector instance
• Ignore selector and log with warning

I'd prefer the first one since a syntactically wrong unique ID can only come from a bug by users of the launcher API. It's like violating a precondition.

[marcphilipp]

Original issue: #171.

[marcphilipp]

Additional Proposals:

• Return an AlwaysFailingTestDescriptor/DeadOnArrivalTestDescriptor/ErrorReportingTestDescriptor
• Pass reporting objec from Launcher into each TestEngine to report unparsable unique IDs, etc.

[marcphilipp]

Since TestEngines now receive an already parsed UniqueId, I think this issue can be closed. The error reporting parts will be addressed in #242.

@junit-team/junit-lambda Thoughts?

[jlink]

Haven't read up on #242 but "unparsable" is different from "unresolvable". Unparsable is handled by parsing upfront. Unresolvable is not.

[marcphilipp]

Fair enough. It seems the issue title and description are out of sync. Would you like to rephrase it to say unresolvable in the description as well?

[jlink]

Should probably be a new issue.

[sbrannen]

FYI: I changed this issue's title to refer to "unparseable" unique IDs.

[sbrannen]

Note that consistent parsing of unique IDs was addressed in #810.

[sbrannen]

Closing this issue since it has been effectively superseded by #242 and #810.