Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #18647 > unrolled thread

can't throw

Back to article view | Back to comp.lang.java.programmer

Contents

  can't throw bob smith <bob@coolfone.comze.com> - 2012-09-11 13:16 -0700
    Re: can't throw markspace <-@.> - 2012-09-11 13:34 -0700
      Re: can't throw Lew <lewbloch@gmail.com> - 2012-09-11 14:15 -0700
    Re: can't throw Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-09-11 17:02 -0400
      Re: can't throw Lew <lewbloch@gmail.com> - 2012-09-11 14:17 -0700
        Re: can't throw Arne Vajhøj <arne@vajhoej.dk> - 2012-09-11 21:21 -0400
          Re: can't throw Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2012-09-11 21:59 -0700
            Re: can't throw Gene Wirchenko <genew@ocis.net> - 2012-09-12 09:18 -0700
              Re: can't throw Robert Klemme <shortcutter@googlemail.com> - 2012-09-12 19:09 +0200
              Re: can't throw markspace <-@.> - 2012-09-12 10:56 -0700
              Re: can't throw Arne Vajhøj <arne@vajhoej.dk> - 2012-09-12 18:36 -0400
                Re: can't throw Gene Wirchenko <genew@ocis.net> - 2012-09-12 18:29 -0700
                  Re: can't throw Patricia Shanahan <pats@acm.org> - 2012-09-12 18:34 -0700
                  Re: can't throw Arne Vajhøj <arne@vajhoej.dk> - 2012-09-12 21:37 -0400
                    Re: can't throw Arne Vajhøj <arne@vajhoej.dk> - 2012-09-12 21:54 -0400
            Re: can't throw Jim Janney <jjanney@shell.xmission.com> - 2012-09-12 11:27 -0600
            Re: can't throw Arne Vajhøj <arne@vajhoej.dk> - 2012-09-12 18:24 -0400
              Re: can't throw Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2012-09-13 22:20 -0700
                Re: can't throw Gene Wirchenko <genew@ocis.net> - 2012-09-14 09:49 -0700
                  Re: can't throw Robert Klemme <shortcutter@googlemail.com> - 2012-09-14 20:50 +0200
                    Re: can't throw Lew <lewbloch@gmail.com> - 2012-09-14 13:02 -0700
                      Re: can't throw Gene Wirchenko <genew@ocis.net> - 2012-09-14 14:06 -0700
                    Re: can't throw Gene Wirchenko <genew@ocis.net> - 2012-09-14 13:16 -0700
                      Re: can't throw Robert Klemme <shortcutter@googlemail.com> - 2012-09-14 23:07 +0200
                        Re: can't throw Lew <lewbloch@gmail.com> - 2012-09-14 14:28 -0700
                          Re: can't throw Gene Wirchenko <genew@ocis.net> - 2012-09-16 20:04 -0700
          Re: can't throw Arne Vajhøj <arne@vajhoej.dk> - 2012-09-12 18:16 -0400
            Re: can't throw Lew <lewbloch@gmail.com> - 2012-09-12 23:15 -0700
          Re: can't throw Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-09-14 17:33 -0500
            Re: can't throw Robert Klemme <shortcutter@googlemail.com> - 2012-09-16 15:46 +0200
              Re: can't throw Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-09-16 12:17 -0500
                Re: can't throw Robert Klemme <shortcutter@googlemail.com> - 2012-09-16 22:36 +0200
                  Re: can't throw Gene Wirchenko <genew@ocis.net> - 2012-09-16 20:07 -0700
                    Re: can't throw Robert Klemme <shortcutter@googlemail.com> - 2012-09-17 07:41 +0200
                      Re: can't throw Gene Wirchenko <genew@ocis.net> - 2012-09-17 09:51 -0700
                        Re: can't throw Robert Klemme <shortcutter@googlemail.com> - 2012-09-17 21:00 +0200
                          Re: can't throw Gene Wirchenko <genew@ocis.net> - 2012-09-17 13:23 -0700
                      Re: can't throw Joerg Meier <joergmmeier@arcor.de> - 2012-09-17 18:52 +0200
                        Re: can't throw Lew <lewbloch@gmail.com> - 2012-09-17 11:22 -0700
                    Re: can't throw Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-09-17 02:52 -0500
                  Re: can't throw Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-09-17 02:39 -0500
                    Re: can't throw Robert Klemme <shortcutter@googlemail.com> - 2012-09-17 21:02 +0200
    Re: can't throw markspace <-@.> - 2012-09-11 14:28 -0700
    Re: can't throw Arne Vajhøj <arne@vajhoej.dk> - 2012-09-11 21:14 -0400
      Re: can't throw Arne Vajhøj <arne@vajhoej.dk> - 2012-09-12 18:11 -0400
    Re: can't throw Robert Klemme <shortcutter@googlemail.com> - 2012-09-12 08:31 +0200
      Re: can't throw bob smith <bob@coolfone.comze.com> - 2012-09-12 11:40 -0700
        Re: can't throw Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-09-12 15:50 -0400
        Re: can't throw Lew <lewbloch@gmail.com> - 2012-09-12 12:52 -0700
          Re: can't throw Robert Klemme <shortcutter@googlemail.com> - 2012-09-12 23:24 +0200
            Re: can't throw Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-09-12 15:10 -0700
              Re: can't throw Robert Klemme <shortcutter@googlemail.com> - 2012-09-13 23:32 +0200
      Re: can't throw Arne Vajhøj <arne@vajhoej.dk> - 2012-09-12 18:06 -0400
    Re: can't throw Roedy Green <see_website@mindprod.com.invalid> - 2012-09-12 20:55 -0700

Page 3 of 3 — ← Prev page 1 2 [3]

#18798

Robert Klemme <shortcutter@googlemail.com> wrote:
> 
> My point was not that it can't be made "safe".  I rather questioned 
> whether the additional complexity introduced in the language would be 
> beneficial (even if we let compatibility issues aside for the moment).

I don't think there is any additional complexity -- it's just a
different expression of the complexity that today is expressed through
the Throwable hierarchy.

It's certainly not something I suggest we introduce into Java _now_ --
just what I wish they'd done originally. (Or rather, I wish they'd
done something along those lines originally, instead of tying it to
the class hierarchy.)

-- 
Leif Roar Moldskred

[toc] | [prev] | [next] | [standalone]

#18811

On 17.09.2012 09:39, Leif Roar Moldskred wrote:
> Robert Klemme <shortcutter@googlemail.com> wrote:
>>
>> My point was not that it can't be made "safe".  I rather questioned
>> whether the additional complexity introduced in the language would be
>> beneficial (even if we let compatibility issues aside for the moment).
>
> I don't think there is any additional complexity -- it's just a
> different expression of the complexity that today is expressed through
> the Throwable hierarchy.

No, there is more complexity: you have the class hierarchy and 
_additionally_ you define at throwing site how the exception needs to be 
handled.  With the current language design that distinction is bound to 
the exception type while the suggested approach allows to vary handling 
per exception type; hence there are more degrees of freedom and 
consequently more complexity.

Kind regards

	robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[toc] | [prev] | [next] | [standalone]

#18658

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.

[toc] | [prev] | [next] | [standalone]

#18661

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

[toc] | [prev] | [next] | [standalone]

#18708

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

[toc] | [prev] | [next] | [standalone]

#18665

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/

[toc] | [prev] | [next] | [standalone]

#18686

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 a class 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 and started. 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();

[toc] | [prev] | [next] | [standalone]

#18689

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
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#18690

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

[toc] | [prev] | [next] | [standalone]

#18696

On 12.09.2012 21:52, Lew wrote:
> 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

I find the wording of this answer unfortunate: you create a thread of 
execution by invoking Thread.start().  Bob, what you probably meant was 
there are two ways to create functionality executed in a separate 
thread.  But then Lew's comment applies:

> 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:

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

Exactly.  Again: why are you doing this, Bob?

> Why are you subclassing Thread in the first place?

Most people's answers in this thread revolve around the fact how a 
method without declared checked exceptions can be made to throw 
exceptions anyway.  But: 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.  Instead, you should be 
handling exceptions in run() and terminate the thread gracefully (i.e. 
by returning from run()).

> 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.

:-)

Kind regards

	robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[toc] | [prev] | [next] | [standalone]

#18707

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?

[toc] | [prev] | [next] | [standalone]

#18749

On 09/13/2012 12:10 AM, Daniel Pitts wrote:
> 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.

Right, I completely forgot about that.  The issue with this is that you 
have far less context than inside method run().  So handling there is 
certainly preferred.

>> 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?

... other than the default uncaught exception handler.  Exactly.

Kind regards

	robert

[toc] | [prev] | [next] | [standalone]

#18706

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

[toc] | [prev] | [next] | [standalone]

#18721

On Tue, 11 Sep 2012 13:16:38 -0700 (PDT), bob smith
<bob@coolfone.comze.com> wrote, quoted or indirectly quoted someone
who said :

>
>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.

try throwing an IllegalArgumentException or the like instead.  You
don't need to declare it.
-- 
Roedy Green Canadian Mind Products http://mindprod.com
A new scientific truth does not triumph by convincing its opponents and making them see the light,
but rather because its opponents eventually die, and a new generation grows up that is familiar with it.
~ Max Planck 1858-04-23 1947-10-04 

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | comp.lang.java.programmer

csiph-web