can't throw

Discussion in 'Java' started by bob smith, Sep 11, 2012.

  1. bob smith

    bob smith Guest

    Am I the only one who wanted to throw an Exception but couldn't because I was overriding
    a method that threw nothing?

    In particular, I'm subclassing Thread and can't throw an Exception in the run method. I suspect this is a more general issue though.
     
    bob smith, Sep 11, 2012
    #1
    1. Advertising

  2. bob smith

    markspace Guest

    On 9/11/2012 1:16 PM, bob smith wrote:
    > Am I the only one who wanted to throw an Exception but couldn't
    > because I was overriding a method that threw nothing?
    >
    > In particular, I'm subclassing Thread and can't throw an Exception in
    > the run method. I suspect this is a more general issue though.
    >


    Not really. Either modify the signature of the parent class, or throw a
    subclass of RuntimeException. Easy-peasy.

    Never throw RuntimeException directly; it'll mean nothing to you or
    anyone else reading a stack trace. Always throw some subclass with a
    meaningful type.
     
    markspace, Sep 11, 2012
    #2
    1. Advertising

  3. bob smith

    Eric Sosman Guest

    On 9/11/2012 4:16 PM, bob smith wrote:
    > Am I the only one who wanted to throw an Exception but couldn't because I was overriding
    > a method that threw nothing?


    Happens all the time.

    > In particular, I'm subclassing Thread and can't throw an Exception in the run method. I suspect this is a more general issue though.


    The usual answer is to throw some kind of RuntimeException,
    with the original Exception as its "cause." For example,

    void method() { // no "throws"
    try {
    somethingThatCanThrow();
    } catch (IOException ex) {
    throw new IllegalStateException(
    "Fertilizer on fan", ex);
    }
    }

    IllegalArgumentException and IllegalStateException are the
    wrappers I find myself using most; there are plenty of others,
    and of course you can implement your own RuntimeException subclass
    if nothing seems suitable to the situation.

    Some people, deeper thinkers than I, consider the whole
    business of checked exceptions a nuisance or a misfeature. The
    need for a dodge like the above can be seen as evidence for
    that viewpoint, but I don't find it overwhelmingly convincing.
    In any event, that's Java As It Is And Is Likely To Remain, so
    we've got to get used to it whether we sneer at it or not.
    Personally, I find it helpful that the compiler reminds me when
    I've forgotten to deal with a checked exception; the inconvenience
    of wrapping checked in unchecked exceptions seems a minor matter.

    --
    Eric Sosman
    d
    "The speed at which the system fails is usually not important."
     
    Eric Sosman, Sep 11, 2012
    #3
  4. bob smith

    Lew Guest

    markspace wrote:
    > bob smith wrote:
    >> Am I the only one who wanted to throw an Exception but couldn't
    >> because I was overriding a method that threw nothing?


    If you're talking about a checked exception, yes.

    If an overridden method throws a check exception not thrown by its
    parent implementation, it would break code that calls the method through
    the parent type.

    As markspace points out, this is not a problem with unchecked exceptions.

    >> In particular, I'm subclassing Thread and can't throw an Exception in
    > > the run method. I suspect this is a more general issue though.


    Well, duh.

    The issue is you aren't supposed to break code that uses the parent type.

    > Not really. Either modify the signature of the parent class, or throw a
    > subclass of RuntimeException. Easy-peasy.
    >
    > Never throw RuntimeException directly; it'll mean nothing to you or
    > anyone else reading a stack trace. Always throw some subclass with a
    > meaningful type.


    And meaningful message.

    --
    Lew
     
    Lew, Sep 11, 2012
    #4
  5. bob smith

    Lew Guest

    Eric Sosman wrote:
    > bob smith wrote:
    >> Am I the only one who wanted to throw an Exception but couldn't because I was overriding
    >> a method that threw nothing?

    >
    > Happens all the time.
    >
    >> In particular, I'm subclassing Thread and can't throw an Exception in the run method. I suspect this is a more general issue though.

    >
    > The usual answer is to throw some kind of RuntimeException,
    > with the original Exception as its "cause." For example,
    >
    > void method() { // no "throws"
    > try {
    > somethingThatCanThrow();
    > } catch (IOException ex) {
    > throw new IllegalStateException(
    > "Fertilizer on fan", ex);
    > }
    > }
    >
    >
    > IllegalArgumentException and IllegalStateException are the
    > wrappers I find myself using most; there are plenty of others,
    > and of course you can implement your own RuntimeException subclass
    > if nothing seems suitable to the situation.
    >
    > Some people, deeper thinkers than I, consider the whole
    > business of checked exceptions a nuisance or a misfeature. The


    Those people are mistaken.

    > need for a dodge like the above can be seen as evidence for
    > that viewpoint, but I don't find it overwhelmingly convincing.


    Not even suggestive, much less convincing.

    > In any event, that's Java As It Is And Is Likely To Remain, so


    and for good reason.

    > we've got to get used to it whether we sneer at it or not.
    > Personally, I find it helpful that the compiler reminds me when
    > I've forgotten to deal with a checked exception; the inconvenience
    > of wrapping checked in unchecked exceptions seems a minor matter.


    --
    Lew
     
    Lew, Sep 11, 2012
    #5
  6. bob smith

    markspace Guest

    On 9/11/2012 1:16 PM, bob smith wrote:

    > In particular, I'm subclassing Thread and can't throw an Exception in
    > the run method. I suspect this is a more general issue though.
    >



    I missed "I'm subclassing Thread" earlier. Yes, it is a general issue.
    In general, use an Executor, and separate the work to do (a "task" or
    Runnable/Callable) and the Thread. They're two different things,
    really, and you shouldn't try to combine them or need to subclass Thread
    at all.

    Executors seem complicated when you read the docs but really they're
    very simple to use and provide a lot of capability that would be tough
    to try to do on your own.

    <http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/Executor.html>

    Don't over look Executors or ExecutorService mentioned in those docs.
     
    markspace, Sep 11, 2012
    #6
  7. bob smith

    Arne Vajhøj Guest

    On 9/11/2012 4:16 PM, bob smith wrote:
    > Am I the only one who wanted to throw an Exception but couldn't because I was overriding
    > a method that threw nothing?
    >
    > In particular, I'm subclassing Thread and can't throw an Exception in the run method. I suspect this is a more general issue though.


    You are not the first with that problem.

    My take is:
    * if the API is well designed the the intent must be that the class
    is supposed to handle the problems and not throw an exception
    at all, and you should follow that guideline
    * if the API is not well designed and someone just forgot about
    exceptions, then you must consider what is best:
    - change the API with all the problems arising from that
    - throw a runtime exception

    Arne
     
    Arne Vajhøj, Sep 12, 2012
    #7
  8. bob smith

    Arne Vajhøj Guest

    On 9/11/2012 5:17 PM, Lew wrote:
    > Eric Sosman wrote:
    >> Some people, deeper thinkers than I, consider the whole
    >> business of checked exceptions a nuisance or a misfeature. The

    >
    > Those people are mistaken.
    >
    >> need for a dodge like the above can be seen as evidence for
    >> that viewpoint, but I don't find it overwhelmingly convincing.

    >
    > Not even suggestive, much less convincing.
    >
    >> In any event, that's Java As It Is And Is Likely To Remain, so

    >
    > and for good reason.


    I must admit that personally I like the checked exception
    context.

    But given that languages invented after Java chose not to
    implement checked exceptions, then we must conclude that
    it has not caught on.

    (primarily thinking of C# and Scala here)

    So the benefits are not that obvious to everyone.

    Arne
     
    Arne Vajhøj, Sep 12, 2012
    #8
  9. On 11.09.2012 22:16, bob smith wrote:
    > Am I the only one who wanted to throw an Exception but couldn't
    > because I was overriding a method that threw nothing?
    >
    > In particular, I'm subclassing Thread and can't throw an Exception in
    > the run method. I suspect this is a more general issue though.


    Why are you subclassing Thread in the first place?

    Kind regards

    robert

    --
    remember.guy do |as, often| as.you_can - without end
    http://blog.rubybestpractices.com/
     
    Robert Klemme, Sep 12, 2012
    #9
  10. On Tue, 11 Sep 2012 21:59:16 -0700, Peter Duniho
    <> wrote:

    >On Tue, 11 Sep 2012 21:21:38 -0400, Arne Vajhøj wrote:
    >
    >> [...]
    >> But given that languages invented after Java chose not to
    >> implement checked exceptions, then we must conclude that
    >> it has not caught on.
    >>
    >> (primarily thinking of C# and Scala here)
    >>
    >> So the benefits are not that obvious to everyone.

    >
    >And more to the point, those other languages do not seem to suffer greatly,
    >if at all, from the lack of checked exceptions.
    >
    >For whatever reason, I've never found checked exceptions a compelling
    >feature. It's absolutely in the right spirit, one which I agree
    >wholeheartedly with. And yet I find that at least in the Java
    >implementation, it seems to create more headaches than it prevents.


    To me, it also seems as if it would be a good idea, but using it
    is awkward. In some coursework, I used a Java cryptographic system.
    It had a lot of exceptions to handle so my code had a lot of catches.
    Because I did not know what was thrown, I wrote my code without them
    and then added whatever the compiler stated was missing. In those
    catches, there really was not anything that I could do other than
    reporting the error.

    I prefer reading the main flow of execution as a high-level
    story. Catches interrupt this. When there are a lot of catches, they
    make the main code harder to find.

    >I realize I'm in the minority here. But it's a viewpoint I feel needs to
    >be expressed.


    Thank you.

    Sincerely,

    Gene Wirchenko
     
    Gene Wirchenko, Sep 12, 2012
    #10
  11. On 12.09.2012 18:18, Gene Wirchenko wrote:
    > To me, it also seems as if it would be a good idea, but using it
    > is awkward. In some coursework, I used a Java cryptographic system.
    > It had a lot of exceptions to handle so my code had a lot of catches.
    > Because I did not know what was thrown, I wrote my code without them
    > and then added whatever the compiler stated was missing. In those
    > catches, there really was not anything that I could do other than
    > reporting the error.


    Well, but that's a valid way to handle an exception. :)

    > I prefer reading the main flow of execution as a high-level
    > story. Catches interrupt this. When there are a lot of catches, they
    > make the main code harder to find.


    I my experience that can at least partially be attributed to people
    putting several try catch blocks in a method or not making them the
    outermost "bracket" of the method. I frequently see a return after the
    closing bracket or such thing which makes it harder to read (and decide
    what happens in case of error and OK) and - more importantly -
    impossible for the compiler to catch control flow errors (e.g. the final
    return returns true while in case of error you wanted to return false).

    Kind regards

    robert

    --
    remember.guy do |as, often| as.you_can - without end
    http://blog.rubybestpractices.com/
     
    Robert Klemme, Sep 12, 2012
    #11
  12. bob smith

    Jim Janney Guest

    Peter Duniho <> writes:

    > On Tue, 11 Sep 2012 21:21:38 -0400, Arne Vajhøj wrote:
    >
    >> [...]
    >> But given that languages invented after Java chose not to
    >> implement checked exceptions, then we must conclude that
    >> it has not caught on.
    >>
    >> (primarily thinking of C# and Scala here)
    >>
    >> So the benefits are not that obvious to everyone.

    >
    > And more to the point, those other languages do not seem to suffer greatly,
    > if at all, from the lack of checked exceptions.
    >
    > For whatever reason, I've never found checked exceptions a compelling
    > feature. It's absolutely in the right spirit, one which I agree
    > wholeheartedly with. And yet I find that at least in the Java
    > implementation, it seems to create more headaches than it prevents.
    >
    > I realize I'm in the minority here. But it's a viewpoint I feel needs to
    > be expressed.
    >


    The major problem I had with checked exceptions was fixed in Java 1.4,
    when they introduced a standard way to wrap exceptions without losing
    the original stack trace. Java 7 lets you handle all the bogus
    exceptions in a single catch clause, so there's a minor nuisance gone.

    And if you really need it, there's always

    public static void throwChecked(final Exception e) {
    class Thrower {
    public Thrower() throws Exception {
    throw e;
    }
    }

    try {
    Thrower.class.newInstance();
    } catch (InstantiationException e1) {
    throw new RuntimeException(e1); // bogus exception: cannot happen
    } catch (IllegalAccessException e1) {
    throw new RuntimeException(e1); // bogus exception: cannot happen
    }
    }

    Not that I recommend doing this, but it *is* possible...

    --
    Jim Janney
     
    Jim Janney, Sep 12, 2012
    #12
  13. bob smith

    markspace Guest

    On 9/12/2012 9:18 AM, Gene Wirchenko wrote:

    > I prefer reading the main flow of execution as a high-level
    > story. Catches interrupt this. When there are a lot of catches, they
    > make the main code harder to find.



    Well true, but these sorts of things yield easily to a little thought
    and planning.

    Given some method or collection of methods that throw a lot of
    exceptions, throwsALot(), you can just separate out the exception
    handling from the rest of the code.

    private void implementation()
    throws This, That, Another
    {
    throwsALot();
    }

    public void handlers() {
    try {
    implementation();
    } catch( This ex ) {
    } catch( That ex ) {
    } catch( Another ex ) {
    }

    Now at least your bothersome exception handling is separate from your
    implementation, and you can read the code a bit more easily. One
    exception in Java 7 is probably AutoClosable, which you should probably
    take advantage of when available.
     
    markspace, Sep 12, 2012
    #13
  14. bob smith

    bob smith Guest

    On Wednesday, September 12, 2012 1:32:01 AM UTC-5, Robert Klemme wrote:
    > On 11.09.2012 22:16, bob smith wrote:
    >
    > > Am I the only one who wanted to throw an Exception but couldn't

    >
    > > because I was overriding a method that threw nothing?

    >
    > >

    >
    > > In particular, I'm subclassing Thread and can't throw an Exception in

    >
    > > the run method. I suspect this is a more general issue though.

    >
    >
    >
    > Why are you subclassing Thread in the first place?
    >
    >
    >
    > Kind regards
    >
    >
    >
    > robert
    >
    >
    >
    > --
    >
    > remember.guy do |as, often| as.you_can - without end
    >
    > http://blog.rubybestpractices.com/


    There are two ways to create a new thread of execution. One is to declare aclass to be a subclass of Thread. This subclass should override the run method of class Thread. An instance of the subclass can then be allocated andstarted. For example, a thread that computes primes larger than a stated value could be written as follows:

    class PrimeThread extends Thread {
    long minPrime;
    PrimeThread(long minPrime) {
    this.minPrime = minPrime;
    }

    public void run() {
    // compute primes larger than minPrime
    . . .
    }
    }

    The following code would then create a thread and start it running:

    PrimeThread p = new PrimeThread(143);
    p.start();
     
    bob smith, Sep 12, 2012
    #14
  15. bob smith

    Eric Sosman Guest

    On 9/12/2012 2:40 PM, bob smith wrote:
    >
    > There are two ways to create a new thread of execution. [...]


    A splendid explanation! May I have your permission to quote it?
    (I'll cite you as the original author, naturally).

    --
    Eric Sosman
    d
     
    Eric Sosman, Sep 12, 2012
    #15
  16. bob smith

    Lew Guest

    bob smith wrote:
    > Robert Klemme wrote:
    > > Why are you subclassing Thread in the first place?

    >
    > There are two ways to create a new thread of execution. One is to declare a class to be a subclass of


    There are far more than two ways.

    > Thread. This subclass should override the run method of class Thread. An instance of the subclass
    > can then be allocated and started. For example, a thread that computes primes larger than a stated
    > value could be written as follows:


    Are you quoting something here?

    You explained what you're doing, but you didn't answer Robert's question of why.

    Why are you subclassing Thread in the first place?

    It's abnormal and you aren't doing anything that obviously calls for this idiom.

    "Because I can!" only answers a certain question asked of a male dog.

    --
    Lew
     
    Lew, Sep 12, 2012
    #16
  17. bob smith

    Arne Vajhøj Guest

    On 9/12/2012 2:31 AM, Robert Klemme wrote:
    > On 11.09.2012 22:16, bob smith wrote:
    >> Am I the only one who wanted to throw an Exception but couldn't
    >> because I was overriding a method that threw nothing?
    >>
    >> In particular, I'm subclassing Thread and can't throw an Exception in
    >> the run method. I suspect this is a more general issue though.

    >
    > Why are you subclassing Thread in the first place?


    If he thinks his class is-a Thread, then why not.

    And implementing Runnable would not avoid the problem anyway.

    Arne
     
    Arne Vajhøj, Sep 12, 2012
    #17
  18. bob smith

    Daniel Pitts Guest

    On 9/12/12 2:24 PM, Robert Klemme wrote:
    > there is no point in throwing from Thread.run()
    > or Runnable.run() other than catastrophic failures (all Errors such as
    > OOM, all RuntimeExceptions which are really programmer mistakes) because
    > you cannot customize handling of exceptions thrown from the run()
    > method: this method is only invoked from class Thread and probably
    > others in the Java standard library itself.

    Actually, you can handle exceptions from a Thread. There is the
    UncaughtExceptionHandler:
    <http://docs.oracle.com/javase/7/docs/api/java/lang/Thread.UncaughtExceptionHandler.html>

    Though the only valuable use I have ever seen from this is in logging
    those failures differently than the default output.

    > Instead, you should be
    > handling exceptions in run() and terminate the thread gracefully (i.e.
    > by returning from run()).


    Agreed. If you need some other code to propagate an Exception, you need
    to pass that information along. Exceptions are meant to unwind the
    stack. For most practical purposes a Thread's run() method really has no
    stack to unwind. Even if you could throw an Exception from it, where
    would that Exception go? Who's going to deal with it?
     
    Daniel Pitts, Sep 12, 2012
    #18
  19. bob smith

    Arne Vajhøj Guest

    On 9/11/2012 9:14 PM, Arne Vajhøj wrote:
    > On 9/11/2012 4:16 PM, bob smith wrote:
    >> Am I the only one who wanted to throw an Exception but couldn't
    >> because I was overriding
    >> a method that threw nothing?
    >>
    >> In particular, I'm subclassing Thread and can't throw an Exception in
    >> the run method. I suspect this is a more general issue though.

    >
    > You are not the first with that problem.
    >
    > My take is:
    > * if the API is well designed the the intent must be that the class
    > is supposed to handle the problems and not throw an exception
    > at all, and you should follow that guideline
    > * if the API is not well designed and someone just forgot about
    > exceptions, then you must consider what is best:
    > - change the API with all the problems arising from that
    > - throw a runtime exception


    Specifically about the Thread and run case: what would be
    the point in throwing an exception? What code should do
    something about it?

    (well - I guess Thread.setDefaultUncaughtExceptionHandler can
    be used, but it is not going to be pretty)

    Arne
     
    Arne Vajhøj, Sep 12, 2012
    #19
  20. bob smith

    Arne Vajhøj Guest

    On 9/11/2012 9:21 PM, Arne Vajhøj wrote:
    > On 9/11/2012 5:17 PM, Lew wrote:
    >> Eric Sosman wrote:
    >>> Some people, deeper thinkers than I, consider the whole
    >>> business of checked exceptions a nuisance or a misfeature. The

    >>
    >> Those people are mistaken.
    >>
    >>> need for a dodge like the above can be seen as evidence for
    >>> that viewpoint, but I don't find it overwhelmingly convincing.

    >>
    >> Not even suggestive, much less convincing.
    >>
    >>> In any event, that's Java As It Is And Is Likely To Remain, so

    >>
    >> and for good reason.

    >
    > I must admit that personally I like the checked exception
    > context.


    It makes a lot of sense if you are API centric.

    A contract "I will either return a value of type X or throw
    one of the exceptions E1,...,En" seems a lot more strict than
    "I will either return a value of type X or throw an exception
    but I will not tell you which".

    Arne
     
    Arne Vajhøj, Sep 12, 2012
    #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. Kerri
    Replies:
    2
    Views:
    13,091
    Kevin Spencer
    Oct 27, 2003
  2. Paul
    Replies:
    1
    Views:
    431
    Adam Maass
    Aug 14, 2003
  3. Ken
    Replies:
    2
    Views:
    10,947
    Mike Schilling
    Feb 26, 2004
  4. Replies:
    15
    Views:
    7,707
    Roedy Green
    Sep 8, 2005
  5. Emanuele D'Arrigo

    To throw or to throw not?

    Emanuele D'Arrigo, Nov 14, 2008, in forum: Python
    Replies:
    6
    Views:
    341
    Emanuele D'Arrigo
    Nov 15, 2008
Loading...

Share This Page