0

Should .NET provide the ability for programmers to optionally define a set of "checked exceptions" for an abstract method, or optionally in general?

I understand the reasons checked exceptions are not part of .NET and I prefer not having mandatory checked exceptions language-wide, but why not provide an optional syntax which could be useful in some situations? Take the following example, or if you just wanted to specify that some code handle certain exceptions:

public abstract class AbClass
{
    public abstract ISomeInterface AbMethod() throws AbMethodException;

    public void LargerMethod()
    {
        // some processing

        try
        {
            ISomeInterface data = AbMethod();
        }
        catch(AbMethodException ex)
        {
            // some special code
        }

        // some more processing
    }
}

Where now an implementation of AbMethod() would be required to throw AbMethodException.

public class MyAbClass : AbClass
{
    public ISomeInterface AbMethod() throws AbMethodException
    {
        // attempt to create data
        if(dataAlreadyExists)
        {
            throw new AbMethodException();
        }
        else
        {
            // create data
            ISomeInterface obj = (ISomeInterface)(new object());
            obj.WriteData();

            return obj;
        }
    }
}

Would this be a useful feature for you? Thoughts?

ulty4life
  • 2,972
  • 1
  • 25
  • 31
  • Possible duplicate: http://stackoverflow.com/questions/124143/why-are-exceptions-not-checked-in-net –  Dec 22 '10 at 22:30
  • This might be interesting: http://www.artima.com/intv/handcuffs.html (insight from Anders Hejlsberg) – Vlad Dec 22 '10 at 22:30
  • ulty4life: See the second answer on that question. I think that's what you're looking for. –  Dec 22 '10 at 22:31
  • 1
    Put // in front of that. If you get this into the C# syntax by some kind of miracle then I'll find out where you live and hurt you. Although I might tire from waiting in line. Anders gets to be first, of course. – Hans Passant Dec 22 '10 at 22:37
  • 1
    I remember in the java days i'd write a try catch just because of a checked exception and not do anything in the catch with a thought to come back later and refactor (well, i'd log it). I'd put a comment in the catch and then it sits like this for years. If anything, it seemed like a bad practice to me. I consider documenting it in C# with a markup to be more valuable. – Sergey Akopov Dec 22 '10 at 22:37
  • I interpret many of Anders' reasons for not including it in .NET to be because 90% of the time it's not useful or misused. The case of the example abstract class, I believe, falls into the other 10%. There is code that expects an exception to be thrown. Why shouldn't it be able to define which exception it can expect. I'm not proposing that this be required functionality, but rather *could* it be syntactically optional to define the checking / exception type? It wouldn't be a closed set of exceptions - others could be thrown, but a particular one is required. – ulty4life Dec 22 '10 at 22:58

1 Answers1

2

This might fail horribly if the correct implementation of one of your interface methods was to thow NotImplementedException. In that case, the addition of the "checked exception" does nothing but prevent someone who needs to implement the interface from being able to do so.

Mike Hofer
  • 16,477
  • 11
  • 74
  • 110
  • The idea isn't that it prevents other exceptions from being thrown, but that an implementation of that method must *at least* throw the specified exceptions. – ulty4life Dec 22 '10 at 23:07
  • 1
    @ulty4life That doesn't make any sense. – Craig Gidney Dec 22 '10 at 23:24
  • I don't see how if other exceptions are allowed to be thrown that this in any way prevents someone from creating an implementation. – ulty4life Dec 23 '10 at 01:35