2

In .net, how do I make the guy that writes a subclass aware that they need to code for a specific exception type that a base class may throw? Ideally I'm looking to force a developer to either try..catch the exception or perform necessary validation prior to the exception occuring... Can I perhaps use attributes to force a developer to code for the exception?

For example....

I have some code that calls a "Save" method. Before save is called on the object, I have an intercepting class that provides some validation. If a class is not in a valid state then I throw an exception (what I'm looking at is not my code, so not using an exception is not an acceptable solution at this point...), what I'm wondering is how I make clear to a consumer of my code that they should be checking for the potential exception and coding for it or at least performing checks so that the exception will not occur...?

So in simple terms (my code uses a lot of interfaces etc, so this is just a simple example...)

class SavableObject {
    public static void Save(){
        // validation
        ValidationClass.BeforeSave();
        // then do the save... 
        DoSave();
    }
    public static void DoSave(){
        // serialize...
    }
}

class ValidationClass {
    public static void BeforeSave(T cls){
        // perform some checks on class T
        // THROW EXCEPTION if checks fail
    }
}

So in this example a consumer of my code would inherit from SavableObject as follows and can then call save... eg...

class NewSavableThing: SavableObject
{
    public static void Save(){
        base.Save();
        // calls inherited save method which may throw an exception
        // At this point the exception may still occur, and the person writing this 
        // code may not know that the exception will occur, so the question is how do 
        // I make this clear or force the developer of this class to code for 
        // the possibility that the exception may occur?!
    }
}

I'm wondering if I could use a set of attributes such that I could force the guy building a subclass to code for the exception... eg...

class SavableObject {
    [DeveloperMustCatchException(T)] // specifies that the exception type must be caught
    public static void Save(){ ... }
}


class NewSaveableThing: SavableObject {
    [ExceptionIgnored] / [ExceptionCaught] // specifies that the developer is aware 
    // that the exception needs catching/dealing with, I am assuming that 
    // if this attribute is not provided then the compiler will catch 
    // and prevent a successful compile...
    public static void Save() {
    }
}

Any pointers much appreciated...

EDIT: to clarify - I want to force the developer to acknowledge that the exception exists, such that the developer cannot be ignorant of the exception. Ideally the compiler will stop the compilation if either a [ExceptionIgnored] attribute or an [ExceptionHandled] (or similar) attribute is missing... This would indicate that the exception has been considered. I dont mind the exception being ignored, what I'm trying to do is make sure that the next developer is aware of the existence of the exception - if that makes sense. I know that in the /// comment I can document the exception...

I ask because I have a couple of students working with us that are not aware of the exceptions and do not read all the documentation, even tho the exceptions have been documented. I cannot check every line of code they write, so I was hoping to force them to acknowledge exception and have the compiler check for me that the exception has been considered... Whether they code for the exception is their choice as long as they are aware of its existence...

0909EM
  • 4,761
  • 3
  • 29
  • 40

4 Answers4

4

Use XML documentation (the /// comments in your method header), specifically the exception tag:

The tag lets you specify which exceptions can be thrown.

It's enough to let people know an exception can occur. They can decide to catch it or to let it escalate.

EDIT

In fact, you would ilke to have Java's throws keyword. Unfortunately, it does not exist in C#.

Community
  • 1
  • 1
Gert Arnold
  • 105,341
  • 31
  • 202
  • 291
  • Agreed the /// will provide a comment - but I want the compiler to do the checking, so that a developer cannot simply be ignorant of the exception... – 0909EM Aug 25 '12 at 18:28
  • 1
    Yes, but they should not have the obligation to catch it. It's their responsibility to not be ignorant. It should be enough to document it. – Gert Arnold Aug 25 '12 at 18:32
  • Now your talking about checked vs unchecked exceptions? This is not what I want... I was hoping that I could use attributes to enforce the programmers obligations to consider (not necessarily deal with) the exception... – 0909EM Aug 25 '12 at 18:51
  • 1
    Yes, I see your point and I understand your motivation, I just dont't agree :) . It's always a risk to have students write production code. Urge them to write unit tests! – Gert Arnold Aug 25 '12 at 18:56
1

Developers shouldn't be forced to catch and handle exceptions in their code. If their code can't reasonably recover from the cause of the exception, it shouldn't be caught, and the exception should bubble up.

Daniel Mann
  • 57,011
  • 13
  • 100
  • 120
  • OK - I can appreciate that - but I want the compiler to do as much checking as possible, such that the developer can choose to ignore the exception, but can't be ignorant of it occuring... – 0909EM Aug 25 '12 at 18:27
1

There is no way to have the compiler do what you are asking for. The closest you can get to have the compiler check for correctness of an object state is with code contracts http://msdn.microsoft.com/en-us/library/dd264808.aspx

Jared Shaver
  • 1,339
  • 8
  • 12
  • This is probably the closest answer I'm going to get... Ideally I'd have checks performed at compile time, but I agree this is probably the closest I'll get... – 0909EM Aug 25 '12 at 19:03
1

I think the cleanest way to handle this case is to use a template method to do the save and require subclasses to provide an implementation of an error handler if an exception is thrown:

public abstract class SaveableObject
{
    public void Save()
    {
        try
        {
            ValidationClass.BeforeSave();
            this.SaveCore();
        }
        catch(ExceptionType ex)
        {
            OnSaveException(ex);
        }
    }

    protected abstract void OnSaveException(ExceptionType ex);
    protected abstract void SaveCore();
}
Lee
  • 142,018
  • 20
  • 234
  • 287
  • 1
    @0909EM - I'm not sure what you mean - this code won't compile if authors of subclasses fail to acknowledge the exception by overriding the handler method. – Lee Aug 25 '12 at 19:06
  • Sorry! Yes, your correct... it will check at compile time! (Call it a senior moment?!) The more I think about it the more I like this solution... This would be much easier than concocting something with attributes/code contracts etc!!! – 0909EM Aug 25 '12 at 19:15
  • For the record: I agree that it does what you want on a local level but it is impossible to apply this pattern everywhere where you want to enforce exception awareness. Soon you will run into inheritance restrictions (no multiple inheritance) to mention one thing. And what about consumers of `Save()`? What to do if `OnSaveException` does not "eat" an exception but re-throws it? – Gert Arnold Aug 25 '12 at 19:55