Documented exceptions in interfaces

[brfnblks]

Hello,

Exceptional is a great plug-in, really well done! 👍
But today I recognized that exceptions which are documented within a component are not shown in the interface to this component, which calls the method, which has a documented exception.

Is there any possibility to solve this problem?

Thank you for following answers.

[jongleur1983]

I'm not sure if it's useful to warn on the interface itself, as that may be implemented outside of the accessible code by other implementations throwing arbitrary exceptions.

A slightly different approach might be to discover exceptions on interface usage transparently:
When a method is called on an interface, a warning could be emitted for any exception type any known implementation throws.

[cmeeren]

I'd very much like to see the suggestion by @jongleur1983 implemented.

[cmeeren]

Is there any chance of the suggestion by @jongleur1983 being implemented? As it currently stands, Exceptional is more or less useless when making heavy use of interfaces (e.g. for DI), which is a shame, because it's a great extension.

[jongleur1983]

@cmeeren I'm happy to assist with anything if there's a reasonable proposal on how this might work.
Biggest showstopper for now (conceptually) seems to be that exceptions are not declared on interfaces and the implementing classes might not be known.

Let's consider an interface A and classes A1, A2, A3 implementing A.
Let's assume, A1 throws Exceptions of type E1, A2 throws Exceptions of type E2 and A3 throws exceptions of type E3.

First question: What's the expected behaviour of Exceptional now?
To work reliably, Exceptional would have to demand for documentation of all three types on the interface (that is, E1, E2 and E3), because as any of the implementations may be used for A, any can be thrown.

So far from a technical point of view this would be possible to implement if - and only if - all possible implementations of the A are known to Exceptional: Any implementation in external code or libraries may be hidden in binary files representing compiled code, so that Exceptional even in theory can't get the required information.

What might be possible is the other way around, something that may help when coding:

• When writing/editing a class C that implements an interface IC, check if that interface documents all thrown exceptions, and warn if not.
• Code completions given to the developer in class C could be "add exception documentation for exception type E to interface IC", adding the comment.

The overall issue to find all missing exceptions on the other hand might be a different thing, e.g. be used by a roslyn compiler step returning issues for any missing documentation on interfaces, but not sure how that would work exactly.

[cmeeren]

So far from a technical point of view this would be possible to implement if - and only if - all possible implementations of the A are known to Exceptional

Since ReSharper can do solution-wide analysis, I guess this is not a problem?

[jongleur1983]

Additional hint for the topic (got the idea just now): In case the interface in question is marked internal (thus visible inside the project only), we could assume to find all implementations inside the project, because classes outside the project can't see - and thus not implement the interface.

A minor exception to this are external projects marked as "friends" by the InternalsVisibleTo attribute (see https://msdn.microsoft.com/en-us/library/system.runtime.compilerservices.internalsvisibletoattribute(v=vs.110).aspx defined in the AssemblyInfo of the interfaces project (thanks @oopbase for your blogpost).
Main usage for this attribute is, I think, testing (to make internal classes visible to test projects), where it may not be that important that Exceptional can't enforce guidelines.

[ManticSic]

Better late than never... Thanks for that great idea.
This would be a larger change, so first we will fix some smaller ones and than look at this again.

[JeremyMorton]

In general, I consider the exceptions thrown to be a part of an interface's contract, so it would be good to have Exceptional let me know when I have an implementation of an interface that throws more than the interface's contract says it can so that I can expand the interface's contract or not throw different types than the existing contract.