On 27 March 2011 15:03, Reinier Zwitserloot <[email protected]> wrote:
> That's rather oversimplifying matters. In particular, its just not true
> that the pro checked exception camp can "write exactly the same code as
> now". Writing code is an act. It involves more than hitting keys on a
> keyboard. You look at a screen. Your editor tells you things. One of the
> things that'll be changing is that your editor is no longer telling you that
> you forgot to handle a checked exception.
>
> I _DONT_ like checked exceptions all that much and I'll say right now that
> removing them wholesale from java is a very painful idea. Whenever I write
> code calling a method that reports expectable errors via checked exceptions
> (FileNotFoundException for example), even if I remember the exact type of
> that exception, I'll just write the line, wait for the error, and then
> quickfix the error. I'm so used to this that my muscle memory is going to
> have a lot of trouble adjusting to a world where this does not happen.
>
> In the spirit of your argument, what can we pragmatically do for java given
> the need to maintain backwards compatibility? The pipe dreams painted by
> Kevin Wright and other functional fans of basically rewriting APIs to return
> Eithers or CPS or other paradigms is obviously not a solution (to be fair to
> them, that wasn't the discussion then).
>
>
Backward compatibility is, of course, the absolute #1 design goal for Java.
Given the number of lucrative contracts Oracle has for supporting such
compatibility, I can't exactly blame them.
I'm a fan of many things that I know simply can't be added to the language;
the drag of supporting legacy APIs overwhelms any efforts to accelerate into
new features. Java is now in the cobol-esque long tail of its lifespan
This means that any *serious* innovation will have to occur on the platform
and not in the language. So we already have Either and other such
constructs on the JVM, and may even get limited support for such things in
Java-the-language, but the chances of being retrofitted to existing APIs are
slightly less than nil.
The more interesting discussion then becomes the relative merits of
exception handling approaches in other (JVM) languages. Migration is
becoming a serious possibility for many, and this sort of comparison helps
someone decide which direction to take if they are seriously considering
migration.
> I only see 2 workable options:
>
> (A) Define that henceforth all exceptions are to be unchecked. This is
> backwards compatible, in that all code that compiles today will compile
> tomorrow and do the same thing. But, as I said above, this isn't all that
> compatible with muscle memory and existing library designs.
>
> (B) Give an option to officially 'ignore' an exception, meaning you can
> throw / fail to handle a checked exception without declaring that you
> 'throw' it. This change would go along with the ability to catch a checked
> exception even if no statement in the try block appears to throw it,
> generating just a (suppressable) warning, instead of java6's current
> behaviour where this is an error. For example:
>
> public String readWordList() ignores IOException {
> InputStream in = MyClass.class.getResourceAsStream("wordlist.txt");
> ......
> }
>
> The above example is rather poignant, too, as such code will throw an
> IOException exactly as likely as a ClassNotFoundError, which is so far to
> the 'unexpectable and unhandleable' side of the chart that it's not even a
> RuntimeException, it's an Error.
>
I think there's a middle ground here... Make all exceptions unchecked, until
such time as they're declared in a throws clause. You still get checked
exceptions if you want, you still get your finger memory, but you're not
forced to make e.g. an IOException be checked every time you use it..
Converting an exception from checked to unchecked would still require an
explicit rethrow, though you could rethrow exactly the same exception, of
the same type, without having to wrap it.
This should also allow exceptions in existing APIs to be migrated from
checked to unchecked without breaking existing user code.
"ignores" is a nice idea, but an absolute non-starter, you have a snowball's
chance in hell of getting another keyword added to the language
> Is there a serious problem here for those who consider the checked
> exception experiment a total failure? I already know from espousing this
> view elsewhere that checked exception purists don't feel this is pure
> enough. Pointing out that you can effectively ignore exceptions already with
> some fancy generics abuse, or interop with _ANY_ non-java language on the
> JVM, does not appear to help. But what about those who don't want checked
> exceptions at all? Would this be a fair compromise?
>
> --
> You received this message because you are subscribed to the Google Groups
> "The Java Posse" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected].
> For more options, visit this group at
> http://groups.google.com/group/javaposse?hl=en.
>
--
Kevin Wright
gtalk / msn : [email protected]
<[email protected]>mail: [email protected]
vibe / skype: kev.lee.wright
quora: http://www.quora.com/Kevin-Wright
twitter: @thecoda
"My point today is that, if we wish to count lines of code, we should not
regard them as "lines produced" but as "lines spent": the current
conventional wisdom is so foolish as to book that count on the wrong side of
the ledger" ~ Dijkstra
--
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.
