Prev: how to kill a java thread by force?
Next: X11 based GUI toolkit for java on unix AND windows
From: Alessio Stalla on 15 Dec 2009 12:33
On Dec 14, 11:46 am, Arved Sandstrom <dces...(a)hotmail.com> wrote:
> If I read one more blog about what a new language should have (*) where
> the author can't wait to show how "in" he or she is by excoriating
> checked exceptions I'll probably write a new blog "Stupid New Language
> Blogs are Considered Evil." :-)
>
> Seriously, get over it already. The supposed anguish that checked
> exceptions cause - namely, that you can't easily ignore them - is
> exactly the point. I myself have never noticed that this is all that
> much extra work. And what I *have* noticed - time and time again - is
> that an OO language that has only unchecked exceptions leads in general
> to poor error handling. But that's just a real-world observation: if it
> happens to conflict with theory who am I to argue with blog theoreticians?

I don't believe the problem with checked exceptions is that you can't
easily ignore them. Rather, what I don't like about them is that often
they force you to deal with exceptions too early. For example,
consider this scenario:

class A implements interface B. B declares a void doSomething();
method.
To implement B, A uses a method in a library C which can throw a
LibraryCException.
Now A cannot alter the signature of doSomething() to throw a C-
specific exception. But A cannot catch it either, because it doesn't
know how to deal with it: should it cancel the operation? Should it
retry? Should it report failure to the user, and how? etc. So what
does A do? Wrap it in a RuntimeException and rethrow it. The net
effect is that A behaves the same as if LibraryCException were
unchecked, but it includes more boilerplate code (the try-catch needed
to wrap the exception) and obfuscates the exception itself with a
layer of wrapping, making it harder to deal with it at the upper
levels, should the need arise. I see this sort of scenario happening
very often in the kinds of applications I work on (multi-layer J2EE
apps).

Cheers,
Alessio



> Thank you for your attention, and good morning.
>
> AHS
>
> * You know Java is pretty successful when everyone seems to use it as a
> starting point for this discussion, even when they criticize it
> savagely. Java is like democracy - apparently full of warts but nobody
> can devise anything better that keeps as many people reasonably happy.
>
> For the purposes of these "next language" discussions I consider C# to
> be a near-Java. Although personally I do prefer C#.

From: Arne Vajhøj on 16 Dec 2009 19:39
On 15-12-2009 12:33, Alessio Stalla wrote:
> I don't believe the problem with checked exceptions is that you can't
> easily ignore them. Rather, what I don't like about them is that often
> they force you to deal with exceptions too early.

You have the option of passing them on.

> For example,
> consider this scenario:
>
> class A implements interface B. B declares a void doSomething();
> method.
> To implement B, A uses a method in a library C which can throw a
> LibraryCException.
> Now A cannot alter the signature of doSomething() to throw a C-
> specific exception. But A cannot catch it either, because it doesn't
> know how to deal with it: should it cancel the operation? Should it
> retry? Should it report failure to the user, and how? etc. So what
> does A do? Wrap it in a RuntimeException and rethrow it. The net
> effect is that A behaves the same as if LibraryCException were
> unchecked, but it includes more boilerplate code (the try-catch needed
> to wrap the exception) and obfuscates the exception itself with a
> layer of wrapping, making it harder to deal with it at the upper
> levels, should the need arise. I see this sort of scenario happening
> very often in the kinds of applications I work on (multi-layer J2EE
> apps).

That is a problem in the definition of B.

And is really no different from that you really need to pass
an int on to doSomething, but the interface method does
not have an argument.

Bad API not a problem with checked exceptions.

Arne
From: Arne Vajhøj on 16 Dec 2009 19:48
On 15-12-2009 06:06, Leif Roar Moldskred wrote:
> Arne Vajh�j<arne(a)vajhoej.dk> wrote:
>>
>> I don't like the idea of having throwchecked and throwunchecked. It
>> could become very messy with the same exception being both.
>>
>> I seems quite fair to me that the type carry the information whether
>> it is checked or not. If necessary just create two types.
>
> *shrugs* I just don't see checked versus unchecked exceptions as different
> _types_ but rather as different uses. UncheckedWidgetException and
> CheckedWidgetException have the same semantic meaning and the same
> intrinsic behaviour: they're just _thrown_ differently -- and that
> difference is external and not part of their behaviour.

They do something different as checked and unchecked. If they are
different then different types is the most natural.

>> I don't like the extends RuntimeException => unchecked either. @Checked
>> and @Unchecked would be much nicer. But annotations did not exist back
>> then. And now it is too late.
>
> Hmm. Is it? It's too late to get checked-ness separated from the type
> system, but not for @Checked and @Unchecked annotations. As long as this
> property is implicitly inherited until overridden, all Sun would need
> to not break existing code would be to mark Exception as @Checked and
> RuntimeException as @Unchecked.

But that would not clear up things, because extending RuntimeException
or not would still have significance.

>>> To prevent lazy programming, let us add the rule that a method also have
>>> to declare all unchecked exceptions which are thrown _directly_ from
>>> within that method (i.e. thrown by an explicit throw statement in the
>>> method body.)
>>
>> Does not make sense to me.
>
> The idea was to require the same amount of immediate effort (to add a
> throws declaration) when throwing an unchecked exception as when throwing
> a checked exception, so that lazy programmers don't use unchecked
> exceptions just because it's easier there and then.
>
> (Plus, I'd like to see more unchecked exceptions declared in the method
> headers.)

But because you only wanted directly thrown, then that information is
rather useless.

>> Does not make sense to me. The code could just as well be inside
>> the method.
>
> Sure -- but it's one pointless level of indentation removed. Which I'll admit
> isn't a big deal, but then again the code can just as well be on the _outside_
> of the method too.

It is lot easier to read if the code in a method is inside the method.

>> Test on type is an anti-OO thing.
>
> Sure -- but tests on type are what the current catch statements
> are all about too. They're just particularly awkward and limited
> tests on type.

I would call it very nicely encapsulated.

Arne

From: Arne Vajhøj on 16 Dec 2009 19:49
On 15-12-2009 06:10, Andreas Leitgeb wrote:
> Arne Vajhøj<arne(a)vajhoej.dk> wrote:
>>> Then, give us some way to handle more than one type of exception in the
>>> same catch statement. "catch( FooException, BarException, WeirdException ex ) { }"
>> That has been proposed before. I guess it is OK.
>
> I don't quite get it, what would be the actual compiletime type of "ex"
> in the (here empty) catch-block.

Hm. Good question.

Arne
From: Arne Vajhøj on 16 Dec 2009 19:53
On 14-12-2009 23:56, Lew wrote:
> Arne Vajhøj wrote:
>> The equivalent of voting is to join the JCP/ANSI/ISO/ECMA/whatever
>> that actually controls the languages.
>>
>> Writing at a blog is the equivalent of whining over the
>> politicians at the local bar.
>
> Anyway, Arved said "*Stupid* New Language Blogs are Considered Evil",
> not "*Well-reasoned, Intelligent* Blogs ..."
>
> To carry the analogy further, whining at the local bar, writing letters
> to your Congressperson and local newspaper (can you tell I'm from the
> U.S., where we get to do that sort of thing?) and blogging are things
> that influence politicians (at least here in the U.S.). Some of those
> whiners become politicians themselves, perhaps even President or
> Vice-President (as here), even to the point of winning the Nobel Peace
> Prize. Similarly, intelligent whiners with a good point that actually
> makes sense can influence the development and popularity of computer
> languages like Java. In fact, it's programmers who made Java popular in
> the first place.

I believe that to get results an effort has to be made - instead
of whining then do something.

Both in language development and in politics.

Arne
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: how to kill a java thread by force?
Next: X11 based GUI toolkit for java on unix AND windows