Why does Java require the throws clause? Good or bad language design?

Discussion in 'Java' started by James Harris, Feb 7, 2007.

  1. James Harris

    James Harris Guest

    I have a number of books on Java but none seem to answer the
    fundamental question on throws clauses: /why/ force the programmer to
    declare what a method /may/ throw?

    To quote one: "If you write a method that throws an exception, then
    the Java compiler wil require that you do one of two things: you must
    either declare that the method throws the exception using the 'throws'
    keyword, or else you must provide a catch exception handler to catch
    that exception." - Java Programming Explorer.

    Is there really value in Java's behaviour? Or is this an unnecessary
    burden on the programmer? Why not simply accept exceptions can be
    thrown which are not listed, and deal with them in the innermost catch
    clause which matches?

    Conversely, if there is a chain of methods: aa calls bb calls cc calls
    dd, and dd declares that it throws FileNotFoundException, if we don't
    want to handle it in cc do we need to declare that it also throws
    FileNotFoundException... and so on through callers to cc etc?

    In terms of code maintenance, if dd could once throw a given exception
    but now, because the relevant code has been removed, it cannot does cc
    still need to provide for handling the exception simply /because/ it
    is listed in dd's throws clause?

    Any replies appreciated and please keep comp.lang.misc in the
    crosspost list as it's relevant to language design principles. Thanks.
    James Harris, Feb 7, 2007
    #1
    1. Advertising

  2. James Harris

    Alex Hunsley Guest

    Re: Why does Java require the throws clause? Good or bad languagedesign?

    James Harris wrote:
    > I have a number of books on Java but none seem to answer the
    > fundamental question on throws clauses: /why/ force the programmer to
    > declare what a method /may/ throw?
    >
    > To quote one: "If you write a method that throws an exception, then
    > the Java compiler wil require that you do one of two things: you must
    > either declare that the method throws the exception using the 'throws'
    > keyword, or else you must provide a catch exception handler to catch
    > that exception." - Java Programming Explorer.


    The theory is that by mkaing the programmer explicitly acknowledge what
    (checked) exceptions may be thrown, they will deal with them appropriately.
    Of course, it is possible to write:

    catch (Exception e) {
    // nothing
    }

    But then of course the 'blame' lies squarely on the programmer.

    > Is there really value in Java's behaviour?


    Yes.

    > Or is this an unnecessary
    > burden on the programmer?


    There is some burden - obviously declaring "throws" on lots of methods
    can be annoying - but you can use strategies like wrapped exceptions (of
    which I posted in comp.lang.java.programmer in the last few days).

    > Why not simply accept exceptions can be
    > thrown which are not listed,


    The theory is that the lack of explicitness would a bad thing. And if
    you think about it, whether or not a method throws a certain type of
    exception *is* in effect part of that method's interface.


    > and deal with them in the innermost catch
    > clause which matches?


    Doesn't make much sense. Lower down code doesn't always know exactly how
    to handle the exceptional circumstance, and so you'd end up signalling
    to higher levels that something bad happened - so exceptions handle that
    (at some cost, e.g. setup time, but for exceptional circumstances, that
    isn't so bad).

    > Conversely, if there is a chain of methods: aa calls bb calls cc calls
    > dd, and dd declares that it throws FileNotFoundException, if we don't
    > want to handle it in cc do we need to declare that it also throws
    > FileNotFoundException... and so on through callers to cc etc?


    Yup. Or use a wrapped exception to wrap all possible exceptions, hence
    protecting your interfaces from mucho changes everytime some deep code
    throws a new sort of exception (or *stops* throwing some sort).

    > In terms of code maintenance, if dd could once throw a given exception
    > but now, because the relevant code has been removed, it cannot does cc
    > still need to provide for handling the exception simply /because/ it
    > is listed in dd's throws clause?


    Java complains (compile error) if you declare a method as throwing a
    checked exception when in fact it doesn't. So your above situation can't
    happen - it won't compile.

    lex
    Alex Hunsley, Feb 7, 2007
    #2
    1. Advertising

  3. Re: Why does Java require the throws clause? Good or bad languagedesign?

    Dnia 07-02-2007, śro o godzinie 00:11 -0800, James Harris napisał(a):

    > Is there really value in Java's behaviour?


    Some people believe so. Others claim that the cure is worse than the
    disease. I think it's not worth the trouble.

    http://radio.weblogs.com/0122027/stories/2003/04/01/JavasCheckedExceptionsWereAMistake.html
    http://www.mindview.net/Etc/Discussions/CheckedExceptions
    http://www.artima.com/intv/handcuffs2.html

    See also: http://java.sun.com/javase/6/docs/api/java/lang/ThreadDeath.html
    "The class ThreadDeath is specifically a subclass of Error rather than
    Exception, even though it is a "normal occurrence", because many
    applications catch all occurrences of Exception and then discard the
    exception."

    It's easy to imagine *why* many applications are tempted to catch all
    occurrences of Exception and then discard the exception.

    --
    __("< Marcin Kowalczyk
    \__/
    ^^ http://qrnik.knm.org.pl/~qrczak/
    Marcin 'Qrczak' Kowalczyk, Feb 7, 2007
    #3
  4. James Harris

    Lew Guest

    Re: Why does Java require the throws clause? Good or bad languagedesign?

    James Harris wrote:
    >> I have a number of books on Java but none seem to answer the
    >> fundamental question on throws clauses: /why/ force the programmer to
    >> declare what a method /may/ throw?


    Alex Hunsley wrote:
    > The theory is that by mkaing the programmer explicitly acknowledge what
    > (checked) exceptions may be thrown, they will deal with them appropriately.
    > Of course, it is possible to write:
    >
    > catch (Exception e) {
    > // nothing
    > }
    >
    > But then of course the 'blame' lies squarely on the programmer.


    >> Is there really value in Java's behaviour?


    > Yes.


    >> Or is this an unnecessary burden on the programmer?
    >> Why not simply accept exceptions can be
    >> thrown which are not listed,


    > The theory is that the lack of explicitness would a bad thing. And if
    > you think about it, whether or not a method throws a certain type of
    > exception *is* in effect part of that method's interface.


    There are always unchecked exceptions. But Alex is right, in many cases you
    need or want to make the exception part of a method's interface, and declaring
    it so is no different than declaring that a method, say, takes a String arg.
    Does declaring method parameters place an "undue" burden on a programmer?

    If you as a programmer really don't see the value of declaring exceptions,
    don't throw them, or rely entirely on unchecked exceptions. After a while you
    will discover scenarios where dealing with the results thereby is actually
    harder than dealing with checked exceptions.

    One of the major flaws, perhaps the major flaw with much production code is
    that the programmers did not account for all possible exceptional
    circumstances. Such programs fubar on their users all the time. You have to
    take the care as a programmer to deal with things like unexpected inputs, lost
    connections and the myriad of unhappy events that can befall a program.

    With or without exceptions.

    There is no responsible way to avoid this aspect of programming.

    The burden isn't in the declaration of exceptions. Au contraire, exceptions
    help you reduce the burden of dealing with all the corner cases.

    - Lew
    Lew, Feb 7, 2007
    #4
  5. James Harris

    Simon Guest

    Re: Why does Java require the throws clause? Good or bad languagedesign?

    Alex Hunsley wrote:
    > James Harris wrote:
    >> In terms of code maintenance, if dd could once throw a given exception
    >> but now, because the relevant code has been removed, it cannot does cc
    >> still need to provide for handling the exception simply /because/ it
    >> is listed in dd's throws clause?

    >
    > Java complains (compile error) if you declare a method as throwing a
    > checked exception when in fact it doesn't. So your above situation can't
    > happen - it won't compile.


    It will, since overriding methods in subclasses could throw the exception. One
    thing that does not compile is catching an exception that is not thrown. The
    first method compiles, the second does not:

    public class Test {

    public void testThrows() throws java.io.FileNotFoundException {
    }

    public void testCatch() {
    try {
    System.out.println("Test");
    } catch (java.io.FileNotFoundException e) {
    e.printStackTrace();
    }
    }

    }
    Simon, Feb 7, 2007
    #5
  6. James Harris

    Chris Uppal Guest

    Re: Why does Java require the throws clause? Good or bad languagedesign?

    Marcin 'Qrczak' Kowalczyk wrote:

    > > Is there really value in Java's behaviour?

    >
    > Some people believe so. Others claim that the cure is worse than the
    > disease. I think it's not worth the trouble.


    I agree with both those assertions and (fwiw) I largely share your opinion.

    They way the system has been set up, a throws clause is a promise /not/ to
    throw any (checked) exception which is not on the list. There is some value in
    that, but it also puts a burden on the designer of the superclass to anticipate
    all possible subclasses (or else s/he is making a promise that cannot or should
    not be kept). Another way of looking at it is that it couples the design of
    the superclass to its subclasses.

    For instance a file-backed implementation of java.lang.List cannot throw
    IOExceptions relating to failed filesystem operations (no such file, wrong
    permissions, etc). So the implementer is forced into one of several unwelcome
    options. One is just to swallow the errors. Not a good idea ;-) Another is
    to wrap them in unchecked exceptions -- but if we have to do that often then
    clearly the idea of having checked exceptions wasn't too hot in the first
    place. Perhaps the best option is for the "standard" List operations to throw
    unchecked exceptions, but for there to be a different interface which throws
    checked exceptions -- thus clients which "know" that the List is actually a
    DiskBackedList will be able to use the alternate API and thus be alerted to the
    possibility of important failures.

    Which suggests that a better scheme for checked exceptions would have been to
    allow a method to override another method and declare that it throws /more/
    exceptions than the parent. Code which handled the object via a reference of
    the superclass type would not "know" about the extra possible exceptions -- and
    thus would treat them as if they were unchecked. But code which handled the
    object via a reference of the subclass type /would/ see the extended
    definition, and thus the compiler could enforce checking in just the way it
    does in real Java.

    Incidentally, all this enforced checking happens only in the compiler, so it
    would be possible to change or relax the rules without changing the JVM spec
    (very unwelcome); or to use different rules in a Java-like language which
    targeted the same JVM.

    -- chris
    Chris Uppal, Feb 7, 2007
    #6
  7. James Harris

    Andy Dingley Guest

    On 7 Feb, 08:11, "James Harris" <> wrote:
    > /why/ force the programmer to declare what a method /may/ throw?


    I see this as being related to the logic behind the "structured
    programming" movement. (ask your Grandad, it pre-dated OOP) and the
    whole "GOTOs considered harmful" concept.

    The idea was that big programs were too complex to understand, so that
    instead you'd break them into smaller programs that could be treated
    as black boxes, and this required that such boxes could _only_ route
    program flow along a few well-defined pathways - ideally one way in,
    one way out. The enemy of the day was "spaghetti code" where GOTO
    could jump from any location to any other location.

    Requiring the thrown exceptions to be explicitly listed (along with
    the normal end of block execution path) will list the set of all
    possible output routes from a block of code. This allows some black-
    box analysis of the overall program, without worrying too much about
    what happens inside the box.
    Andy Dingley, Feb 7, 2007
    #7
  8. On Wed, 7 Feb 2007, James Harris wrote:
    >
    > I have a number of books on Java but none seem to answer the
    > fundamental question on throws clauses: /why/ force the programmer to
    > declare what a method /may/ throw?
    >
    > To quote one: "If you write a method that throws an exception, then
    > the Java compiler wil require that you do one of two things: you must
    > either declare that the method throws the exception using the 'throws'
    > keyword, or else you must provide a catch exception handler to catch
    > that exception." - Java Programming Explorer.
    >
    > Is there really value in Java's behaviour? Or is this an unnecessary
    > burden on the programmer? Why not simply accept exceptions can be
    > thrown which are not listed, and deal with them in the innermost catch
    > clause which matches?


    You probably know that C++ treats exceptions that way, although I
    think they just did it that way so that you could mix old exceptionless
    (unexceptional?) code with new exception-throwing code.
    Also, if you make exception specifications part of the function's
    "prototype", it would be one more thing to annoy programmers who use
    function pointers. It's bad enough that I can't pass 'strcmp' as the
    fourth argument to 'qsort'; now you're telling me I can't even pass
    'int blah(const void *, const void *) throws(Bletch)' because its
    exception specification doesn't match what 'qsort' expects?

    But those considerations are all due to C++'s legacy from C, and I
    don't think they apply to Java except insofar as a lot of Java programmers
    came over from C and C++ in the early days. Exception handling is still
    arcane enough that "because C++ does it that way" isn't a winning
    argument, the way it is with operator precedence or control structures. :)


    So, what are the benefits of explicitly declaring exception
    specifications? First, psychological reasons; I recommend that
    everyone read Tom Cargill's "Exception Handling: A false sense of
    security", from 1994, which demonstrates how easy it is to forget
    what you're doing when you write code involving exceptions.
    http://www.awprofessional.com/content/images/020163371x/supplements/Exception_Handling_Article.html
    Clearly, having to write exception specifications for all his member
    functions would not have saved Reed; but might it have made him
    think a little bit harder, and maybe eliminated one or two bugs
    out of a dozen?

    Second, there might be technical reasons to prefer that functions
    declare anything they expect to catch, throw, or pass through.
    Obviously we don't /need/ that information, because if we did, it would
    be impossible to compile C++! :) But it might help. See this snippet
    of "exception-handling" code in C, which needs the concept of a "rethrow"
    clause to be implementable in ISO standard C:

    http://en.wikipedia.org/wiki/Talk:Setjmp.h#Nested_catch_blocks

    So if you're translating Java to ISO C, it might be useful. ;)

    [...]
    > In terms of code maintenance, if dd could once throw a given exception
    > but now, because the relevant code has been removed, it cannot does cc
    > still need to provide for handling the exception simply /because/ it
    > is listed in dd's throws clause?


    In terms of code maintenance, heck yes! If the programmer has removed
    DD's ability to throw E, he should also have changed DD's exception
    specification. If the compiler can warn him about his oversight, that's
    a good thing in my book.

    -Arthur
    Arthur J. O'Dwyer, Feb 7, 2007
    #8
  9. On Wed, Feb 07, 2007 at 08:18:08AM -0500, Lew wrote:
    >
    > There are always unchecked exceptions. But Alex is right, in many cases you
    > need or want to make the exception part of a method's interface, and
    > declaring it so is no different than declaring that a method, say, takes a
    > String arg. Does declaring method parameters place an "undue" burden on a
    > programmer?


    That's another good question. My answer would be that it depends on what
    you are doing. If your method only deals with parameters of one type, or
    if it should accept values of any type that is compatible with what the
    method does (e.g. the other methods it calls), then, yes, I would call
    mandatory signature declarations an unnecessary burden. If, on the other
    hand, you want to specialize methods on the types of their arguments
    (polymorphism), then specifying those types is, obviously, necessary.

    > If you as a programmer really don't see the value of declaring exceptions,
    > don't throw them, or rely entirely on unchecked exceptions. After a while
    > you will discover scenarios where dealing with the results thereby is
    > actually harder than dealing with checked exceptions.


    I don't believe so. Just because you do not explicitly list the
    exceptions a method can throw does not mean that this information is not
    available. You can always use (static) analysis to determine which
    exceptions a method could throw.

    You can always implement your own system to enforce that certain
    exceptions are caught or otherwise handled if this proves beneficial in
    your case. It does not have to be hard-coded in the language, forcing
    the burden on situations where the benefits are not as great.

    > The burden isn't in the declaration of exceptions. Au contraire, exceptions
    > help you reduce the burden of dealing with all the corner cases.


    I agree with the second part, but I don't agree that Java's take on
    exceptions is not a burden. Often, the right thing to do with an
    exception is to propagate it up the call stack. Often, the right
    response to an error is to abort the process with an error message. In
    many languages, these are the default behaviors, and you get them for
    free.

    In Java, you are required to write an exception handler if you want a
    checked exception to abort the program with an error message. You also
    have to add checked exceptions to throws clauses if you do not want to
    handle them locally, but want them to propagate up the call stack. These
    are arguably unnecessary efforts that have to be made not once, but
    after certain refactorings, as well.

    The rationale for Java's explicitness and mandatory declarations is that
    they make programs more robust. They have that potential, but the extra
    burden they impose on programmers also means there is less time to
    perform other actions that make programs more robust. Also, it is not
    uncommon for programmers to specify Object as an argument type or
    Exception as an exception type, avoiding some of the burden Java imposes
    on them, but simultaneously throwing away the benefits of the system.
    Still, it demonstrates that, sometimes, Java's way of doing things is
    percieved as less than desirable.

    To conclude, my stance on the issue is that since (1) Java's explicit
    approach is not almays desirable and (2) the benefits of Java's approach
    can be obtained without mandating declarations in all circumstances and
    hardcoding checked exceptions into the language, Java does impose an
    unnecessary burden on programmers, and there are better approaches than
    those Java takes.

    Regards,

    Bob

    --
    No cookies found.
    Robbert Haarman, Feb 7, 2007
    #9
  10. James Harris

    Alex Hunsley Guest

    Re: Why does Java require the throws clause? Good or bad languagedesign?

    Simon wrote:
    > Alex Hunsley wrote:
    >> James Harris wrote:
    >>> In terms of code maintenance, if dd could once throw a given exception
    >>> but now, because the relevant code has been removed, it cannot does cc
    >>> still need to provide for handling the exception simply /because/ it
    >>> is listed in dd's throws clause?

    >> Java complains (compile error) if you declare a method as throwing a
    >> checked exception when in fact it doesn't. So your above situation can't
    >> happen - it won't compile.

    >
    > It will, since overriding methods in subclasses could throw the exception. One
    > thing that does not compile is catching an exception that is not thrown. The
    > first method compiles, the second does not:


    > public class Test {
    >
    > public void testThrows() throws java.io.FileNotFoundException {
    > }
    >
    > public void testCatch() {
    > try {
    > System.out.println("Test");
    > } catch (java.io.FileNotFoundException e) {
    > e.printStackTrace();
    > }
    > }
    >
    > }



    D'oh! Of course, you're right. I was think of exactly what you detail in
    your example there (trying to catch an unthrown exception) and got it
    the wrong way round!
    thanks,
    lex
    Alex Hunsley, Feb 7, 2007
    #10
  11. James Harris

    Alex Hunsley Guest

    Re: Why does Java require the throws clause? Good or bad languagedesign?

    Chris Uppal wrote:
    > Marcin 'Qrczak' Kowalczyk wrote:
    >
    >>> Is there really value in Java's behaviour?

    >> Some people believe so. Others claim that the cure is worse than the
    >> disease. I think it's not worth the trouble.

    >
    > I agree with both those assertions and (fwiw) I largely share your opinion.
    >
    > They way the system has been set up, a throws clause is a promise /not/ to
    > throw any (checked) exception which is not on the list. There is some value in
    > that, but it also puts a burden on the designer of the superclass to anticipate
    > all possible subclasses (or else s/he is making a promise that cannot or should
    > not be kept). Another way of looking at it is that it couples the design of
    > the superclass to its subclasses.
    >
    > For instance a file-backed implementation of java.lang.List cannot throw
    > IOExceptions relating to failed filesystem operations (no such file, wrong
    > permissions, etc). So the implementer is forced into one of several unwelcome
    > options. One is just to swallow the errors. Not a good idea ;-) Another is
    > to wrap them in unchecked exceptions -- but if we have to do that often then
    > clearly the idea of having checked exceptions wasn't too hot in the first
    > place.


    Another possibility is throwing a wrapped checked exception. Obviously,
    that would expose some details of what was going on in the
    implementation, but at least the code handling the wrapped exception
    knows that something went wrong, and has access to the actual 'cause'
    exception inside, if it is interested....
    Alex Hunsley, Feb 7, 2007
    #11
  12. Re: Why does Java require the throws clause? Good or bad languagedesign?

    In article <>,
    Lew <> wrote:
    >
    >There are always unchecked exceptions. But Alex is right, in many cases you
    >need or want to make the exception part of a method's interface, and declaring
    >it so is no different than declaring that a method, say, takes a String arg.
    >Does declaring method parameters place an "undue" burden on a programmer?


    Well, you could always just write
    public void foo(Object... args)
    to get rid of that particular burden :)

    And, of course,
    public void foo(Object... args) throws Throwable
    may be just the silver bullet we are looking for . . .

    Cheers
    Bent D
    --
    Bent Dalager - - http://www.pvv.org/~bcd
    powered by emacs
    Bent C Dalager, Feb 8, 2007
    #12
  13. Re: Why does Java require the throws clause? Good or bad languagedesign?

    In article <45ca0733$0$761$>,
    Chris Uppal <-THIS.org> wrote:
    >Marcin 'Qrczak' Kowalczyk wrote:
    >
    >They way the system has been set up, a throws clause is a promise /not/ to
    >throw any (checked) exception which is not on the list. There is some value in
    >that, but it also puts a burden on the designer of the superclass to anticipate
    >all possible subclasses (or else s/he is making a promise that cannot or should
    >not be kept). Another way of looking at it is that it couples the design of
    >the superclass to its subclasses.


    I would rather think that the superclass designer should only look at
    what sort of conceptual problems could arise from the superclass and
    introduce checked exceptions for those. Implementors of subclasses
    will then be left with the task of mapping their lower-level problems
    to the superclass' higher-level concepts but this shouldn't be too
    unproblematic.

    A general List specification may be declared to throw
    CouldNotInsertExceptions and
    ElementUnreadableExceptions. Implementations of the list will know to
    map their IOExceptions or whatever to those higher-level conditions.

    Of course, having all methods in the superclass throwing some sort of
    checked exception can get tedious for clients of that class.

    >For instance a file-backed implementation of java.lang.List cannot throw
    >IOExceptions relating to failed filesystem operations (no such file, wrong
    >permissions, etc). So the implementer is forced into one of several unwelcome
    >options. One is just to swallow the errors. Not a good idea ;-) Another is
    >to wrap them in unchecked exceptions -- but if we have to do that often then
    >clearly the idea of having checked exceptions wasn't too hot in the first
    >place. Perhaps the best option is for the "standard" List operations to throw
    >unchecked exceptions, but for there to be a different interface which throws
    >checked exceptions -- thus clients which "know" that the List is actually a
    >DiskBackedList will be able to use the alternate API and thus be alerted to the
    >possibility of important failures.


    We might have two different types of List: UnreliableList and
    ReliableList. The former would potentially throw checked exceptions
    from all its methods since it is expected that it may occassionally be
    cut off from its data source (file-based, db-based, network-based,
    etc.) whileas the latter would not as we expect any problems in
    accessing its data would be sufficiently catastrophic to grind the
    rest of the system to a halt anyway (RAM-based storage).

    Cheers
    Bent D
    --
    Bent Dalager - - http://www.pvv.org/~bcd
    powered by emacs
    Bent C Dalager, Feb 8, 2007
    #13
  14. On Thu, Feb 08, 2007 at 10:44:18AM +0000, Bent C Dalager wrote:
    > And, of course,
    > public void foo(Object... args) throws Throwable
    > may be just the silver bullet we are looking for . . .


    It is true that this removes the effort of changing the declaratiens in
    response to refactoring, but Java will still impose burdens on the
    programmer. First, they have to actually type "Object" before every
    argument and "throws Throwable" after every method declaration.
    Secondly, if you actually want to use these arguments and throwables,
    you will have to downcast them to another class, because Object and
    Throwable probably don't have the methods and fields you need. This
    requires more typing. It also incurs a performance penalty, because the
    casts will be checked at run time. In the end, you get the worst of
    dynamic typing and the worst of mandatory declarations, all in one
    program.

    Regards,

    Bob

    --
    That that is is that that is not not, that is, not that that is not.
    Robbert Haarman, Feb 8, 2007
    #14
  15. James Harris

    Lew Guest

    Re: Why does Java require the throws clause? Good or bad languagedesign?

    Bent C Dalager wrote:
    >> And, of course,
    >> public void foo(Object... args) throws Throwable
    >> may be just the silver bullet we are looking for . . .


    Robbert Haarman wrote:
    > In the end, you get the worst of
    > dynamic typing and the worst of mandatory declarations, all in one
    > program.


    Which is why newsgroup readers have to watch out for humorous replies, and not
    try actually to implement them.

    - Lew
    Lew, Feb 8, 2007
    #15
  16. On Thu, Feb 08, 2007 at 07:52:40AM -0500, Lew wrote:
    > Bent C Dalager wrote:
    > >>And, of course,
    > >>public void foo(Object... args) throws Throwable
    > >>may be just the silver bullet we are looking for . . .

    >
    > Robbert Haarman wrote:
    > >In the end, you get the worst of
    > >dynamic typing and the worst of mandatory declarations, all in one
    > >program.

    >
    > Which is why newsgroup readers have to watch out for humorous replies, and
    > not try actually to implement them.


    Point taken.

    On the other hand, people do actually write code like that. Well.
    perhaps not "throws Throwable", but certainly "throws Exception". And
    anyone who has been programming in Java for some time will have seen the
    likes of

    void add(Object o) ...

    and

    ((SomeClass) someContainer.get(someKey)).someMethod(...)

    It's not just misguided programmers that write such code; Java was full
    of it before the type system overhaul.

    Regards,

    Bob

    --
    Two wrongs do not make one right, but three lefts do.
    Robbert Haarman, Feb 8, 2007
    #16
  17. James Harris

    nukleus Guest

    In article <eqeuu2$tec$>, (Bent C Dalager)
    wrote:
    >In article <>,
    >Lew <> wrote:
    >>
    >>There are always unchecked exceptions. But Alex is right, in many cases you
    >>need or want to make the exception part of a method's interface, and declaring

    >
    >>it so is no different than declaring that a method, say, takes a String arg.
    >>Does declaring method parameters place an "undue" burden on a programmer?


    I agree with this position with both hands.

    Exceptions can simplify the code but they have to be
    fine grained and handles properly at each level.
    By declaring that some method throws exception,
    you force the upper layers of your code to handle
    that exception, and you can, if you wish, handle
    the same exception in that same method to display
    some error message of final granularity, and then
    rethrow that same exception to the higher level
    to see if some operation can be retried or do all
    the other things they do on the higher level.

    Once i started introducing the exception mechanism
    in some of old java code, i was unable to compile
    the app for days, because of compiler errors
    "exception is not handled".
    But the more i worked on it, the better the end
    results were.

    Right now, the program handles just about any
    error condition imaginable and displays/logs
    the error messages of the most precise description,
    plus, on the top of it, it can retry just about
    any error condition imaginable, upto simply
    turning the power switch off or unplugging your
    network cable. As soon, as you plug it back in,
    the program will try to redo the LAST operation
    it was doing, without restarting the whole cycle
    from the top.

    Throws clause is probably one of the better benefits
    of the entire exception mechanism. Yes, it forces you
    to hancle those exceptions on the higher level,
    but it all happens during the compile time, preventing
    all sorts of error conditions imaginable in the run time.

    The only thing i suggest in terms of using exceptions
    mechanism in general, is to use fine enough granularity
    exceptions and handle them on the most appropriate level.
    This way, you have about the most powerful structure,
    allowing you to display the error messages of the most
    precistion and, at the same tim, try to recover just
    about any operation imaginable.

    The extreme case: use the exceptions everywhere,
    is simply foolish. First of all, you need to understand
    the very nature of exceptions and it is essentially
    an equivalent of a goto statement, that totally screws
    up your stack and throws your program into place
    you could not have imagine.

    Any program is a fine mix of conditional code
    and exceptions. Yes, purely conditional code approach
    is way too messy as just after about any call,
    you'd have to check on results of it. Otherwise,
    you can not be certain that you can proceed,
    which ends up in large amounts of unnecessary code
    compared to properly used exceptions.

    But...

    You can't just get away from conditional code,
    because it is the VERY NATURE of a program,
    which is logic, and logic, its turn, is a conglomeration
    of ifs and buts.

    If you don't have those ifs and buts,
    you'll end up with the most rigid and inflexible,
    totalitarian system, forcing users to do things
    he could not have imagine in his wildest dreams
    he has to EVER do, going to the point of obscene
    by requiring you to reboot your box in some extreme
    instances.

    Just because those masters of delusion
    do not think that using fine grained ifs and buts
    you'll achieve the most flexible and most pleasant
    and comfortable environment for the USER,
    which is what your entire app is there for on the
    first place.

    >Well, you could always just write
    >public void foo(Object... args)
    >to get rid of that particular burden :)


    Is it supposed to be a joke?

    >And, of course,
    >public void foo(Object... args) throws Throwable
    >may be just the silver bullet we are looking for . . .


    Just about the most foolish thing to do.
    Once you make the declaration of this type,
    you loose ALL the granularity of error condition
    handling, and will NEVER be able to recover from
    errors and attempt to redo only starting from
    the error state in your program and continue on
    after error condition has been removed,
    which is what just about all real life apps do.

    I have over a dozen of custom exceptions
    derived at the most fine grained level of
    standard exceptions, and handle all the exceptions
    starting from the most fine grained
    and going upto Exception level itself,
    which means that you basically have a fatal error.
    It means you have an error condition that was not
    handled by ANY of your mechanism. It could be just
    about the most innocent operation such as division
    by 0, which could be properly handled and the
    default values substituted for the error values
    and the program could keep crunching along.

    Summary:
    You create a number of custom exceptions with fine
    enough granularity to report/handle just about
    ANY error condition imaginable, even in your wildest
    dreams, and giving you the most precise scope of
    error condition that could be handle locally
    to provide the most precise and detailed error
    messages or attempt to recover.

    You HANDLE those exceptions starting from the most
    fine grained level. You may have several levels
    of catch blocks and act upon different exceptions
    differently. In some cases, the operation could
    be recovered by simply restarting the local level
    of it. In other cases, the result could be more
    brutal, in cases where you lost connection to the net,
    or things like that, in which case you'd have to
    retry going from higher levels,
    and in some cases, those errors could be equivalent
    to fatal, in which case you have to decide to either
    stop the program completely, close some frames,
    or restart it from the top.

    "THATs the way you do it".

    Good luck.

    >Cheers
    > Bent D
    nukleus, Feb 8, 2007
    #17
  18. James Harris

    nukleus Guest

    In article <>, Robbert Haarman
    <> wrote:
    >On Thu, Feb 08, 2007 at 10:44:18AM +0000, Bent C Dalager wrote:
    >> And, of course,
    >> public void foo(Object... args) throws Throwable
    >> may be just the silver bullet we are looking for . . .

    >
    >It is true that this removes the effort of changing the declaratiens in
    >response to refactoring, but Java will still impose burdens on the
    >programmer. First, they have to actually type "Object" before every
    >argument and "throws Throwable" after every method declaration.


    throws Throwable means your very design is incorrect
    as you are entirely missing the granularity of your errors.
    You'll never be able to successfuly recover
    and forget about reattempting the operation
    on a fine grained level as you will be thrown
    several layers up.

    >Secondly, if you actually want to use these arguments and throwables,
    >you will have to downcast them to another class, because Object and
    >Throwable probably don't have the methods and fields you need. This
    >requires more typing. It also incurs a performance penalty, because the
    >casts will be checked at run time. In the end, you get the worst of
    >dynamic typing and the worst of mandatory declarations, all in one
    >program.


    A BASIC rule in object oriented programming:

    DO NOT USE CASTS.
    Unless it is absolutely unavoidable.

    >Regards,
    >
    >Bob
    >
    nukleus, Feb 8, 2007
    #18
  19. James Harris

    nukleus Guest

    Re: Why does Java require the throws clause? Good or bad languagedesign?

    In article <>, Lew
    <> wrote:
    >Bent C Dalager wrote:
    >>> And, of course,
    >>> public void foo(Object... args) throws Throwable
    >>> may be just the silver bullet we are looking for . . .

    >
    >Robbert Haarman wrote:
    >> In the end, you get the worst of
    >> dynamic typing and the worst of mandatory declarations, all in one
    >> program.

    >
    >Which is why newsgroup readers have to watch out for humorous replies, and not
    >try actually to implement them.


    I agree with both hands.
    These jokers are nothing more than noise makers,
    having nothing to contribute of just about ANY value
    beyond their "smart ass" image.

    And on a technical group, it isn't even laughable.

    >- Lew
    nukleus, Feb 8, 2007
    #19
  20. James Harris

    nukleus Guest

    In article <>, Robbert Haarman
    <> wrote:
    >On Thu, Feb 08, 2007 at 07:52:40AM -0500, Lew wrote:
    >> Bent C Dalager wrote:
    >> >>And, of course,
    >> >>public void foo(Object... args) throws Throwable
    >> >>may be just the silver bullet we are looking for . . .

    >>
    >> Robbert Haarman wrote:
    >> >In the end, you get the worst of
    >> >dynamic typing and the worst of mandatory declarations, all in one
    >> >program.

    >>
    >> Which is why newsgroup readers have to watch out for humorous replies, and
    >> not try actually to implement them.

    >
    >Point taken.
    >
    >On the other hand, people do actually write code like that. Well.
    >perhaps not "throws Throwable", but certainly "throws Exception".


    Not much different from throws Throwable
    as you loose any and all the precision.
    Basically, your program is screwed beyond repair
    and the entire exceptions mechanism needs to be redesigned.

    >And
    >anyone who has been programming in Java for some time will have seen the
    >likes of
    >
    >void add(Object o) ...
    >
    >and
    >
    >((SomeClass) someContainer.get(someKey)).someMethod(...)
    >
    >It's not just misguided programmers that write such code; Java was full
    >of it before the type system overhaul.
    >
    >Regards,
    >
    >Bob
    >
    nukleus, Feb 8, 2007
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Chris Miller
    Replies:
    4
    Views:
    13,339
    Chris Smith
    Nov 22, 2003
  2. alejandrina

    maintain 'throws' clause?

    alejandrina, Apr 26, 2006, in forum: Java
    Replies:
    1
    Views:
    330
    alejandrina
    Apr 28, 2006
  3. Mr. SweatyFinger
    Replies:
    2
    Views:
    1,840
    Smokey Grindel
    Dec 2, 2006
  4. Arthur J. O'Dwyer
    Replies:
    16
    Views:
    547
    Chris Smith
    Feb 21, 2007
  5. rantingrick
    Replies:
    44
    Views:
    1,204
    Peter Pearson
    Jul 13, 2010
Loading...

Share This Page