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 1 of 3  [1] 2 3  Next page →

#18647 — 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.

[toc] | [next] | [standalone]

#18648

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.

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

#18654

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

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

#18653

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

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

#18655

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

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

#18662

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

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

#18664

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.

Pete

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

#18676

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

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

#18679

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/

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

#18683

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.

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

#18711

On 9/12/2012 12:18 PM, Gene Wirchenko wrote:
> On Tue, 11 Sep 2012 21:59:16 -0700, Peter Duniho
> <NpOeStPeAdM@NnOwSlPiAnMk.com> wrote:
>>
>> 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.

Sounds more like a design problem.

You should catch exceptions at the level where it can be handled
(either where a method can do something that will allow the program
to continue to run or at the outer level where the program can be
terminated).

There is just one thing that is worse than catch everything possible,
report it and continue without doing anything or terminating everywhere
in the code - and that is doing the same thing except not reporting it.

Way too many exceptions is typical a sign of code not properly divided
in layers/components. Such throw layer/component specific exceptions but
hides all the implementation specific exceptions.

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

You should not really have more catches due to checked exceptions.

You should only catch exceptions that you can do something useful
about it. That an exception is checked does not change whether you can
so something useful about it. It just reminds you of its existence.

Arne

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

#18716

On Wed, 12 Sep 2012 18:36:41 -0400, Arne Vajhøj <arne@vajhoej.dk>
wrote:

>On 9/12/2012 12:18 PM, Gene Wirchenko wrote:
>> On Tue, 11 Sep 2012 21:59:16 -0700, Peter Duniho
>> <NpOeStPeAdM@NnOwSlPiAnMk.com> wrote:
>>>
>>> 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.
>
>Sounds more like a design problem.

     I did not write the crypto package.

>You should catch exceptions at the level where it can be handled
>(either where a method can do something that will allow the program
>to continue to run or at the outer level where the program can be
>terminated).

     Well, the level I caught the exception at was the individual
calls to the package.  There were so many exceptions, and it was
really irrelevant what the exception was.  Whatever it was, it meant
that my program had failed.  Writing the glue code to catch each of
these exceptions was simply make-work.

>There is just one thing that is worse than catch everything possible,
>report it and continue without doing anything or terminating everywhere
>in the code - and that is doing the same thing except not reporting it.
>
>Way too many exceptions is typical a sign of code not properly divided
>in layers/components. Such throw layer/component specific exceptions but
>hides all the implementation specific exceptions.
>
>>       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.
>
>You should not really have more catches due to checked exceptions.
>
>You should only catch exceptions that you can do something useful
>about it. That an exception is checked does not change whether you can
>so something useful about it. It just reminds you of its existence.

     I had to catch the exceptions or get a compilation error for each
one I missed.

Sincerely,

Gene Wirchenko

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

#18717

On 9/12/2012 6:29 PM, Gene Wirchenko wrote:
> On Wed, 12 Sep 2012 18:36:41 -0400, Arne Vajhøj <arne@vajhoej.dk>
> wrote:
...
>> You should only catch exceptions that you can do something useful
>> about it. That an exception is checked does not change whether you can
>> so something useful about it. It just reminds you of its existence.
>
>       I had to catch the exceptions or get a compilation error for each
> one I missed.

Or add a throws clause covering the exception to the method declaration.

Patricia

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

#18718

On 9/12/2012 9:29 PM, Gene Wirchenko wrote:
> On Wed, 12 Sep 2012 18:36:41 -0400, Arne Vajhøj <arne@vajhoej.dk>
> wrote:
>> On 9/12/2012 12:18 PM, Gene Wirchenko wrote:
>>> On Tue, 11 Sep 2012 21:59:16 -0700, Peter Duniho
>>> <NpOeStPeAdM@NnOwSlPiAnMk.com> wrote:
>>>>
>>>> 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.
>>
>> Sounds more like a design problem.
>
>       I did not write the crypto package.

No.

But I assume you wrote the code where yous ay you put in all
those catch.

>> You should catch exceptions at the level where it can be handled
>> (either where a method can do something that will allow the program
>> to continue to run or at the outer level where the program can be
>> terminated).
>
>       Well, the level I caught the exception at was the individual
> calls to the package.  There were so many exceptions, and it was
> really irrelevant what the exception was.  Whatever it was, it meant
> that my program had failed.  Writing the glue code to catch each of
> these exceptions was simply make-work.

Definitely sounds as if it was a big mistake to catch the exceptions
where they happened.

>> There is just one thing that is worse than catch everything possible,
>> report it and continue without doing anything or terminating everywhere
>> in the code - and that is doing the same thing except not reporting it.
>>
>> Way too many exceptions is typical a sign of code not properly divided
>> in layers/components. Such throw layer/component specific exceptions but
>> hides all the implementation specific exceptions.
>>
>>>        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.
>>
>> You should not really have more catches due to checked exceptions.
>>
>> You should only catch exceptions that you can do something useful
>> about it. That an exception is checked does not change whether you can
>> so something useful about it. It just reminds you of its existence.
>
>       I had to catch the exceptions or get a compilation error for each
> one I missed.

No.

You has to catch them *or* pass them back the caller by adding throws to
the method signature.

If the method can not really do anything about the exception then
the last option is what should be used.

Arne

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

#18719

On 9/12/2012 9:37 PM, Arne Vajhøj wrote:
> On 9/12/2012 9:29 PM, Gene Wirchenko wrote:
>>       I had to catch the exceptions or get a compilation error for each
>> one I missed.
>
> No.
>
> You has to catch them *or* pass them back the caller by adding throws to
> the method signature.
>
> If the method can not really do anything about the exception then
> the last option is what should be used.

Not:

public class Wrong {
	public static class ExceptionA extends Exception {
	}
	public static class ExceptionA1 extends ExceptionA {
	}
	public static class ExceptionA2 extends ExceptionA {
	}
	public static class ExceptionA3 extends ExceptionA {
	}
	public static class ExceptionB extends Exception {
	}
	public static class ExceptionB1 extends ExceptionB {
	}
	public static class ExceptionB2 extends ExceptionB {
	}
	public static class ExceptionB3 extends ExceptionB {
	}
	public static class ExceptionC extends Exception {
	}
	public static class ExceptionC1 extends ExceptionC {
	}
	public static class ExceptionC2 extends ExceptionC {
	}
	public static class ExceptionC3 extends ExceptionC {
	}
	public static class SomeLib {
		public void a() throws ExceptionA1, ExceptionA2 {
		}
		public void aa() throws ExceptionA2, ExceptionA3 {
		}
		public void b() throws ExceptionB1, ExceptionB2 {
		}
		public void bb() throws ExceptionB2, ExceptionB3 {
		}
		public void c() throws ExceptionC1, ExceptionC2 {
		}
		public void cc() throws ExceptionC2, ExceptionC3 {
		}
	}
	public static void m2() {
		SomeLib lib = new SomeLib();
		try {
			lib.a();
			lib.aa();
			lib.b();
			lib.bb();
			lib.c();
			lib.cc();
		} catch (ExceptionA1 e) {
			e.printStackTrace();
			System.exit(1);
		} catch (ExceptionA2 e) {
			e.printStackTrace();
			System.exit(1);
		} catch (ExceptionA3 e) {
			e.printStackTrace();
			System.exit(1);
		} catch (ExceptionB1 e) {
			e.printStackTrace();
			System.exit(1);
		} catch (ExceptionB2 e) {
			e.printStackTrace();
			System.exit(1);
		} catch (ExceptionB3 e) {
			e.printStackTrace();
			System.exit(1);
		} catch (ExceptionC1 e) {
			e.printStackTrace();
			System.exit(1);
		} catch (ExceptionC2 e) {
			e.printStackTrace();
			System.exit(1);
		} catch (ExceptionC3 e) {
			e.printStackTrace();
			System.exit(1);
		}
	}
	public static void m1() {
		m2();
	}
	public static void main(String[] args) {
		m1();
	}
}

but:

public class Correct {
	public static class ExceptionA extends Exception {
	}
	public static class ExceptionA1 extends ExceptionA {
	}
	public static class ExceptionA2 extends ExceptionA {
	}
	public static class ExceptionA3 extends ExceptionA {
	}
	public static class ExceptionB extends Exception {
	}
	public static class ExceptionB1 extends ExceptionB {
	}
	public static class ExceptionB2 extends ExceptionB {
	}
	public static class ExceptionB3 extends ExceptionB {
	}
	public static class ExceptionC extends Exception {
	}
	public static class ExceptionC1 extends ExceptionC {
	}
	public static class ExceptionC2 extends ExceptionC {
	}
	public static class ExceptionC3 extends ExceptionC {
	}
	public static class SomeLib {
		public void a() throws ExceptionA1, ExceptionA2 {
		}
		public void aa() throws ExceptionA2, ExceptionA3 {
		}
		public void b() throws ExceptionB1, ExceptionB2 {
		}
		public void bb() throws ExceptionB2, ExceptionB3 {
		}
		public void c() throws ExceptionC1, ExceptionC2 {
		}
		public void cc() throws ExceptionC2, ExceptionC3 {
		}
	}
	public static void m2() throws ExceptionA, ExceptionB, ExceptionC {
		SomeLib lib = new SomeLib();
		lib.a();
		lib.aa();
		lib.b();
		lib.bb();
		lib.c();
		lib.cc();
	}
	public static void m1() throws ExceptionA, ExceptionB, ExceptionC {
		m2();
	}
	public static void main(String[] args) {
		try {
			m1();
		} catch (Exception e) {
			e.printStackTrace();
			System.exit(1);
		}
	}
}

Arne

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

#18682

Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> 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

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

#18710

On 9/12/2012 12:59 AM, 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.

They do not seem to suffer in the sense that it does not impact
popularity or general reliability.

It has had a big impact on coding style (at least for C# - I have not
seen sufficient with Scala code to say anything about Scala). The
typical C# program does less exception handling than the typical
Java program.

In theory more exception handling should be better. But I guess
that a pretty big portion of that exception handling simply is
not good enough.

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

It is PITA for writing 25 lines of demo code.

But I really don't see much headache in real programs. One
need to think about the issue anyway.

Arne

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

#18764

On Wed, 12 Sep 2012 18:24:56 -0400, Arne Vajhøj wrote:

> [...]
> It has had a big impact on coding style (at least for C# - I have not
> seen sufficient with Scala code to say anything about Scala). The
> typical C# program does less exception handling than the typical
> Java program.
> 
> In theory more exception handling should be better. But I guess
> that a pretty big portion of that exception handling simply is
> not good enough.

In theory.  But it's not at all clear to me that the extra exception
handling in Java isn't just to work around the fact that checked exceptions
exist.

Just look at this discussion, for example.  You said it yourself: one of
the best ways to deal with the issue is to simply catch and handle the
exception, rather than let it percolate up (i.e. in the context of
overriding an existing API member).

But that is in conflict with another good rule (which you've also stated)
about handling exceptions: only handle exceptions that you can actually
gracefully recover from.

I don't think it's easy to say absent other information whether "more
exception handle should be better" or even whether it should be worse.
Maybe it's better, maybe it's not.

But when a language makes a programmer jump through hoops just to comply
with a syntactical requirement, where in other languages the lack of
hoop-jumping does not appear to result in less-reliable or
less-maintainable code, I start to question just how useful that
hoop-jumping is, even as I tend to agree with the underlying sentiment that
led to it.

Pete

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

#18768

On Thu, 13 Sep 2012 22:20:23 -0700, Peter Duniho
<NpOeStPeAdM@NnOwSlPiAnMk.com> wrote:

>On Wed, 12 Sep 2012 18:24:56 -0400, Arne Vajhøj wrote:

[snip]

>> In theory more exception handling should be better. But I guess
>> that a pretty big portion of that exception handling simply is
>> not good enough.

     It does tend to get something just to shut up the compiler.

>In theory.  But it's not at all clear to me that the extra exception
>handling in Java isn't just to work around the fact that checked exceptions
>exist.

[snipped middle]

>But when a language makes a programmer jump through hoops just to comply
>with a syntactical requirement, where in other languages the lack of
>hoop-jumping does not appear to result in less-reliable or
>less-maintainable code, I start to question just how useful that
>hoop-jumping is, even as I tend to agree with the underlying sentiment that
>led to it.

     Nicely stated.  I am of the same view, and you captured it very
well.

     Unintended consequences are still consequences.

     It may not be nearly as elegant, but I still prefer BASIC's ON
ERROR GOTO handling.  Yes, one had to sort through the error numbers,
but that made it easier in some ways.  One could code something to
handle the few cases where there was a specific handling and then use
a catch-all for the rest.

Sincerely,

Gene Wirchenko

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

#18769

On 14.09.2012 18:49, Gene Wirchenko wrote:

>       It may not be nearly as elegant, but I still prefer BASIC's ON
> ERROR GOTO handling.  Yes, one had to sort through the error numbers,
> but that made it easier in some ways.  One could code something to
> handle the few cases where there was a specific handling and then use
> a catch-all for the rest.

Well, you can do _that_ in Java, too.

I find the distinction between checked and unchecked exceptions pretty 
good - although the distribution of exception types across these 
categories does not always seem to be wisely made in the standard library.

Cheers

	robert

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

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

Page 1 of 3  [1] 2 3  Next page →

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

csiph-web