Why should Exceptions be public? Why ExceptionShouldBeVisibleRule?

[RichB]

I don't understand the reasoning behind ExceptionShouldBeVisibleRule.

If I want an exception to be internal to my assembly and I'm only ever
throwing and catching that exception inside my assembly, why do other
consumers of my assembly have to know about it?


Richard

[Exception]

Hello Richard,
I believe this rule is inspired by the similar existing FxCop rule.

"Rule Description:

An internal exception is only visible inside its own internal scope.
After the exception falls outside the internal scope, only the base
exception can be used to catch the exception. If the internal
exception is inherited from T:System.Exception,
T:System.SystemException, or T:System.ApplicationException, the
external code will not have sufficient information to know what to do
with the exception.
But, if the code has a public exception that later is used as the base
for a internal exception, it is reasonable to assume the code further
out will be able to do something intelligent with the base exception.
The public exception will have more information than what is provided
by T:System.Exception, T:System.SystemException, or
T:System.ApplicationException.

How to Fix Violations:

Make the exception public, or derive the internal exception from a
public exception that is not System.Exception, System.SystemException,
or System.ApplicationException.

When to Exclude Warnings:

Exclude a message from this rule if you are sure in all cases that the
private exception will be caught within its own internal scope."

http://msdn.microsoft.com/en-us/library/bb264484(VS.80).aspx

You cannot really be sure that there is no possibility of an
'internal' exception being thrown to the consumer code that knows
nothing about it.
As I see it, you can avoid this warning and solve the related design
problem by creating a basic publicly visible abstract exception type
like MyApplicationException that inherits from System.Exception and
has some common properties (if any) and making each internal exception
derive from that one. Thus you can ensure that any client code is able
to handle your application's exceptions properly.

Hope this helps,
Dan

[RichB]

On Jul 20, 6:42 pm, Exception <dan.abra...@gmail.com> wrote:
> I believe this rule is inspired by the similar existing FxCop rule.
>

I found that after I'd posted here. It's one of the stupid FxCop
rules. One that _requires_ an FxCop SuppressWarning attribute almost
everywere.

If we're going to have stupid rules, can I suggest the
PotentialDivisionByZero rule everywhere the '/' operator is used. You
would then need to add a SuppressWarning attribute to turn off the
rule.

> You cannot really be sure that there is no possibility of an
> 'internal' exception being thrown to the consumer code that knows
> nothing about it.

Yes I can.

----

public class Test() {

static void Main() {
try {
new Test().Throw();
} catch(TestException) {
Console.WriteLine("Your program failed.");
}

}

private void Thrower() {
throw new TestException();
}

internal class TestException : Exception {
}

----

> As I see it, you can avoid this warning and solve the related design
> problem by creating a basic publicly visible abstract exception type
> like MyApplicationException that inherits from System.Exception and
> has some common properties (if any) and making each internal exception
> derive from that one. Thus you can ensure that any client code is able
> to handle your application's exceptions properly.

In my use-case, I have no 'common properties' to add. My new exception
type is an internal type that simply indicates a _type_ of exception
has occurred. No more details need to be provided. So adding an
intermediate exception in the class hierarchy is pointless
proliferation of types.

Richard