Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   Java (http://www.velocityreviews.com/forums/f30-java.html)
-   -   can't throw (http://www.velocityreviews.com/forums/t952074-cant-throw.html)

bob smith 09-11-2012 08:16 PM

can't throw
 
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.

markspace 09-11-2012 08:34 PM

Re: can't throw
 
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.


Eric Sosman 09-11-2012 09:02 PM

Re: can't throw
 
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
esosman@ieee-dot-org.invalid
"The speed at which the system fails is usually not important."

Lew 09-11-2012 09:15 PM

Re: can't throw
 
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 09-11-2012 09:17 PM

Re: can't throw
 
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

markspace 09-11-2012 09:28 PM

Re: can't throw
 
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.




Arne Vajh°j 09-12-2012 01:14 AM

Re: can't throw
 
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 09-12-2012 01:21 AM

Re: can't throw
 
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



Robert Klemme 09-12-2012 06:31 AM

Re: can't throw
 
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/

Gene Wirchenko 09-12-2012 04:18 PM

Re: can't throw
 
On Tue, 11 Sep 2012 21:59:16 -0700, Peter Duniho
<NpOeStPeAdM@NnOwSlPiAnMk.com> 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


All times are GMT. The time now is 05:24 PM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.