Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > can't throw

Reply
Thread Tools

can't throw

 
 
bob smith
Guest
Posts: n/a
 
      09-11-2012
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.
 
Reply With Quote
 
 
 
 
markspace
Guest
Posts: n/a
 
      09-11-2012
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.

 
Reply With Quote
 
 
 
 
Eric Sosman
Guest
Posts: n/a
 
      09-11-2012
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
http://www.velocityreviews.com/forums/(E-Mail Removed)d
"The speed at which the system fails is usually not important."
 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      09-11-2012
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
 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      09-11-2012
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
 
Reply With Quote
 
markspace
Guest
Posts: n/a
 
      09-11-2012
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.



 
Reply With Quote
 
Arne Vajh°j
Guest
Posts: n/a
 
      09-12-2012
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


 
Reply With Quote
 
Arne Vajh°j
Guest
Posts: n/a
 
      09-12-2012
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


 
Reply With Quote
 
Robert Klemme
Guest
Posts: n/a
 
      09-12-2012
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/
 
Reply With Quote
 
Gene Wirchenko
Guest
Posts: n/a
 
      09-12-2012
On Tue, 11 Sep 2012 21:59:16 -0700, Peter Duniho
<(E-Mail Removed)> 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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
To throw or to throw not? Emanuele D'Arrigo Python 6 11-15-2008 04:12 PM
clocking muxing, plz throw some light sudeepts@gmail.com VHDL 1 02-23-2006 06:43 PM
JNI's throw new does not throw an exception yarona@m-sys.com Java 15 09-08-2005 08:36 AM
throw an application wide event in an asp.net page PrashanthNagaraj ASP .Net 2 11-24-2003 12:48 AM
Throw Exception Vs Throw New Exception Kerri ASP .Net 2 10-27-2003 02:13 PM



Advertisments