Can we reduce the amount of custom DynamicProxy exception types?

[stakx]

DynamicProxy currently defines four exception types:

• GeneratorException
• InvalidMixinConfigurationException
• InvalidProxyConstructorArgumentsException
• ProxyGenerationException

The uses of these exceptions can be roughly summarized as follows:

• User code invokes DynamicProxy incorrectly. In many instances, a ArgumentException or InvalidOperationException could be thrown instead.
• Something truly unexpected happens, e.g. because of a possible bug. In these few circumstances, it would seem proper to throw a custom exception type.

In none of these circumstances would user code profit from catching the exceptions thrown by DynamicProxy, so there's really no point in having distinct exception types.

I may have glossed over some details in my summary above, nevertheless I would suggest that we reduce the amount of custom exception types in DP by (1) using standard FCL exception types where appropriate, and (2) using a single ProxyGenerationException (or perhaps better, a new, more generally named DynamicProxyException) for truly exceptional situations.

(If we do that, we may get rid of GeneratorException and thus the Castle.DynamicProxy.Generators sub-namespace in the public API. See #517 for the full argument.)

[jonorossi]

I definitely like the idea of using FCL exceptions (e.g. ArgumentException and InvalidOperationException) instead of a custom exception because you provide your own message anyway. Why we've got GeneratorException and ProxyGenerationException it strange.

I recall DP also throws TargetException and TargetInvocationException during execution of proxies if things blow up (but they might be captured as inner exceptions), so agree there is no need for multiple custom exceptions.

If you put together a PR probably using a single DynamicProxyException and FCL exceptions where it makes sense I'm happy to review it.

[jonorossi]

The pull requests were all great, I'm happy with all the changes. Thrown exceptions definitely follow a clean pattern now.

[stakx]

@jonorossi, I'm glad you were happy with the changes. I couldn't quite shake the feeling that those PRs were a bit messy, but that was perhaps unavoidable, given the many case-by-case decisions necessary. It feels good to have those exceptions out of the way now!

[jonorossi]

I couldn't quite shake the feeling that those PRs were a bit messy, but that was perhaps unavoidable, given the many case-by-case decisions necessary.

I didn't feel that way. The commit messages made it easy to follow your thought process.