«

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

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

On Wed, 12 Sep 2012 18:36:41 -0400, Arne Vajhøj <>
wrote:

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

On 9/12/2012 9:29 PM, Gene Wirchenko wrote:
> On Wed, 12 Sep 2012 18:36:41 -0400, Arne Vajhøj <>
> wrote:
>> On 9/12/2012 12:18 PM, Gene Wirchenko wrote:
>>> On Tue, 11 Sep 2012 21:59:16 -0700, Peter Duniho
>>> <> 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

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

On Tue, 11 Sep 2012 13:16:38 -0700 (PDT), bob smith
<> 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

Arne Vajhøj wrote:
> Arne Vajhøj wrote:
>> 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".

Agreed, although some chafe at the restriction, and point out
that other code works just fine without such things.

In some cases that's because the platform implicitly supports
some exception-handling mechanism that wraps more than what
Java's does, or the language uses some assertion-like mechanism
to render exceptions moot.

Java's checked exceptions serve a real but optional need, not
only to be strict, but to warn API users (yes, this is an
API-centric or API-ontologic view) of expected exceptions.

Otherwise all exceptions are RuntimeExceptions or worse, and
by definition come as a surprise.

By convention and just the way it works out, RuntimeExceptions
are for program(mer) errors. The infamous NPE is an example.
Most use cases are better served by explicit null guards than
exception tosses.

Not to say that RuntimeExceptions aren't useful; they are.
The suggestions here to wrap checked exceptions in them
are an example. That's because an exception visible to one
thread from another are a surprise, and most likely a
program(mer) error. *Especially* because checked exceptions
are by definition expected and should usually not propagate
outside their thread.

Into logs, yes. As exceptions, not.

Throwing 'Exception' itself is a Dark Art. You can play
with poison - there are valid reasons to do so.

'Error' and raw 'Throwable' - whatever the interpretation here,
it's a bad-ass event.

Like all programming idioms, when you write exceptions
you should have a good flair for their purpose. Arne makes
sense - balances a case for their utility with a recognition
of both their limits and that people do without them.

As he says overthread, "One needs to think about the issue anyway."
Exceptions provide one way to express the decisions you make on
how to handle it.

A key for me is an idea that some code path is exceptional,
and another is a "happy" path. Another key is that I pair
(not) throwing an exception with an assertion.

Example:

public void foo(Bar param)
{
if (param == null || param.getBaz() != State.READY)
{
throw new IllegalStateException("Bad param "+param);
}
assert param != null && param.getBaz() == State.READY;
. . .
}

--
Lew
All rules of thumb are useful as far as they go. But no farther.
As a rule.

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

On Thu, 13 Sep 2012 22:20:23 -0700, Peter Duniho
<> 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

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/