If throwing System.Exception is considered so bad, why wasn\'t Exception made ab
ID: 642914 • Letter: I
Question
If throwing System.Exception is considered so bad, why wasn't Exception made abstract in the first place?
That way, it would not be possible to call:
throw new Exception("Error occurred.");
This would enforce using derived exceptions to provide more details about the error that occurred.
For example, when I want to provide a custom exception hierarchy for a library, I usually declare an abstract base class for my exceptions:
public abstract class CustomExceptionBase : Exception
{
/* some stuff here */
}
And then some derived exception with a more specific purpose:
public class DerivedCustomException : CustomExceptionBase
{
/* some more specific stuff here */
}
Then when calling any library method, one could have this generic try/catch block to directly catch any error coming from the library:
try
{
/* library calls here */
}
catch (CustomExceptionBase ex)
{
/* exception handling */
}
Is this a good practice?
Would it be good if Exception was made abstract?
EDIT : My point here is that even if an exception class is marked abstract, you can still catch it in a catch-all block. Making it abstract is only a way to forbid programmers to throw a "super-wide" exception. Usually, when you voluntarily throw an exception, you should know what type it is and why it happened. Thus enforcing to throw a more specific exception type.
Explanation / Answer
I don't know the actual reasons why it was done this way, and to a certrain degree I agree that preventing infintely wide exceptions from being thrown would be a good thing.
BUT... when coding small demo apps or proof-of-concepts, I don't want to start designing 10 different exception sub-classes, or spending time trying to decide which is the "best" exception class for the situation. I'd rather just throw Exception and pass a string that explains the details. When it's throw-away code, I don't care about these things and if I was forced to care about such things, I'd either create my own GenericException class and throw that everywhere, or move to a different tool/language. For some projects, I agree that properly creating relevant Exception subclasses is important, but not all projects require that.