I suggest you ...

Add support for Java style "throws" keyword

In Java, "throws" keyword is used in method signatures, informing about the exceptions may arise from this method.

public void ReadFile() throws IOException, FileNotFoundException { ... }

When developer use this method, Java compiler forces the developer to implement an exception handling strategy, surrounding this method with try-catch, or adding these exceptions to the new method's signature..

public void UseReadFile()
{
try {
ReadFile();
}
catch(IOException ioex)
{ ... }
catch(FileNotFoundException fnfex)
{ ... }
}

public void UseReadFile throws IOException, FileNotFoundException
{
ReadFile();
}

158 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Uğur Tılıkoğlu shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

    45 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      Submitting...
      • Peter Lawrey commented  ·   ·  Flag as inappropriate

        That would be awesome feature! It will prevent implementations from breaking the contract. After all the thrown exceptions ARE part of the interface/contract. Imagine you have the IUser interface with method GetEmail() that throws RetrievalException. Now I can safely have an LdapUser and DbUser I'll be sure that both throw RetrievalException on failure instead of let's say LdapException or DbException.

      • Hansjörg commented  ·   ·  Flag as inappropriate

        Never ever! Expect the unexpected! there in no way to predict what could go wrong. and defining the list of throwable exceptions automatically ties the interface to the implementation of a method. image Person getPerson(int index) throw SQLException and then later you decide to switch to XML or JSON for the storage. That would easily break all kinds of things.... I've been working in Java teams and everybody got confused about the Java exception handling

      • Guy commented  ·   ·  Flag as inappropriate

        I think it's a great idea, IF you wont force it like java does, make it optional, and most important, don't throw compile time errors, just mark it where try catch is forgotten

      • JaykeBird commented  ·   ·  Flag as inappropriate

        Please no! :( I can understand its usefulness in Java, but it also gets rather annoying. Using the XML documentation in C#, you can list (using "<exception ... />") the exceptions your method can throw. I think that should be good enough.

      • Julian commented  ·   ·  Flag as inappropriate

        The Trouble With Checked Exceptions (Anders Hejlsberg, Bruce Eckel, Bill Venners)
        http://www.artima.com/intv/handcuffs.html

        Why doesn't C# have checked exceptions? (MSDN blog) http://blogs.msdn.com/b/csharpfaq/archive/2004/03/12/why-doesn-t-c-have-checked-exceptions.aspx

        Checked exceptions: Java’s biggest mistake: http://literatejava.com/exceptions/checked-exceptions-javas-biggest-mistake/

      • Daniel Earwicker commented  ·   ·  Flag as inappropriate

        Not that I'm much of a Java defender, but it should be noted that this "feature" is in fact OPTIONAL in Java. If your exception is derived from RuntimeException then you don't have to declare it in order to throw it. It's just that the docs advise you to derive from Exception instead.

        But it's still a bad idea. The stack is not static, it's dynamic. This is true as soon as a language has "callbacks", which Java had in version 1 because methods can be overridden in a derived class. This means that the stack is a many-layered "sandwich" of methods written by independent teams. Checked exceptions just don't work in this reality. They only appear to make sense in very simple, unrealistic examples.

      • Dmitriy Krasnikov commented  ·   ·  Flag as inappropriate

        ?????????? why ????????????
        Even Java as a high level language should not have it. It's just something that should be handled behind the scenes.

      • Al Rodriguez commented  ·   ·  Flag as inappropriate

        I like the idea more from a tools perspective. I don't like that in Java you are required to handle the exception, but in C# I would love it if the tools told me an exception was possible.

      • Sergey Sagan commented  ·   ·  Flag as inappropriate

        This is a horrible, horrible idea, please do not implement it. It makes for ugly overly verbose code

      • Akash Kava commented  ·   ·  Flag as inappropriate

        Then use Java. This is the worst feature of Java, it forces me to write throws Exception in every method that l write.

      • Thaina commented  ·   ·  Flag as inappropriate

        This is a good feature for interface

        But in C# world, instead of force to catch, It should be just a suggestion for intellisense to be able to tell you what exception could be thrown when you using try and catch then it should have list of exception possible to thrown from this try block

        So instead of constraint, it should be native attribute [ThrownExceptionAttribute<X,Y,Z>]

      • Ricardo Bartolomeu commented  ·   ·  Flag as inappropriate

        This feature is a major source of problems in the Java world, (in Java it may break interface definitions).
        But the worst that it does is forcing you to handle an exceptions that you don't want, sometimes I just want to bubble an exception because I don't know what to do it it. Period!

        Not to mention that in a certain way this breaks one of OO pilars: "Encapsulation", each time you change your internals, if your exceptions change, then you have to make it visible, everyone that uses your method will have to rewrite theirs just because your internals have change.

        But... no one has "the time" for that, so what they do is to simply swallow the exception, (great design).

        So... what about no? ;-)

      ← Previous 1 3

      Feedback and Knowledge Base