Re: Java 7 features

On Jul 3, 5:31 am, Hendrik Maryns <hendrik_mar...@xxxxxxxxxxxxx>
wrote:
@ Removing checked exceptions

The only thing that I definitely support is the last one, but probably
in the unusual way: indeed, get rid of checked exceptions, by making
*all* exceptions checked.
For the skeptic: it can be done, see how Eiffel handles it.

Are you out of your cotton-picking MIND?! I don't want to have to
declare every method as "throws RuntimeException" just because just
about everything might throw NPE and any of several other assorted
bounds, arithmetic, etc. exceptions. And if you want Error declared
too, just forgeddaboudit.

You'd have to massively redesign the language to make this have any
beneficial effect, instead of people just slapping "throws
RuntimeException" on everything. For starters, you'd have to have
fields, parameters, and locals that could be null or could not be, say
with

String foo = whatever;
String? bar;

meaning foo is a String, and bar may be a String or null, to make this
at all workable. A lot of code that would generate NPE will simply not
compile without explicitly handling the possibility of a null then,
but it also means they'd have to rewrite the whole standard library(!)
and everyone would have to rewrite their legacy code(!!) ... if they'd
done this from the beginning it would have been a good idea, but
changing it now would trigger chaos that'd make the last-minute
scrambling to fix Y2K bugs look like a Sunday picnic. Note that non-
nullable fields would be required to be explicitly initialized or else
assigned in every constructor, whether directly or by constructor
chaining. The example above explicitly initializes the String foo. A
local variable would have to be assigned immediately on being declared
if it could not be null, e.g. String foo = whatever; but never String
foo. That alone would break nearly all code. A more minor alternative
is:

String! foo = whatever;
String bar;

Again bar is the one that can be null, but all legacy code works. But
you wouldn't see a decrease in implicitly NPE-capable code until the
new !-declarations became widespread in currently-used codebases, and
only then might having to declare this exception be anything but a
massive PITA. On the flip side, the ? version above would be a massive
PITA whether or not NPE became a checked exception at the same time...

And of course there's still the potential for the NPE to crop up at
runtime. The String!/String or String/String? distinction would
probably only exist at compile time, like generic type parameters do
now. Even if it did exist at run time, it would have to do something
if an attempt was made to assign null to the wrong reference, and the
obvious thing is to eagerly throw the NPE that would otherwise happen
anyway but happen further from the location of the buggy code.

Oh, and speaking of generics and type erasure, the #2 exception on the
official 10 Most Annoying If They Became Checked Exceptions list
is ... you guessed it ... ClassCastException...

.

Relevant Pages

  • Re: Neue Attribute einem Objekt =?ISO-8859-1?Q?hinzuf=FCgen?=
    ... Mit dem statsichen Typsystem hat das also nichts zu tun, sondern nur mit der Frage, ob Exceptions checked oder unchecked sein sollen. ... Für mich checked Exceptions zumindest mal was statisches und Fallen damit in die gleiche Kategorie wie das Typsystem. ... An diversen Stellen hat man code der Art "info".equalsstehen, wobei str der besagte String ist und natürlich nicht an jeder Stelle "info" als Vergleichswert herangezogen wird. ... Denn selbst wenn ich den Typ von str ändere, habe ich noch immer einen falschen Methodenaufruf drin. ...
    (de.comp.lang.java)
  • Re: Question concerning object-oriented programming
    ... If at the end of the constructor the ... return defaults such as zero, a null string, or null. ... can also throw exceptions from methods. ... toString() in there. ...
    (comp.programming)
  • Re: Control = StrConv([Control], 3)
    ... Scott ... >> Fred- I think a list of exceptions would be best, I can only see a handful ... > Function ConvExceptionsInField(StrIn As String) As String ... > Dim strWord As String ...
    (microsoft.public.access.formscoding)
  • Cant understand why these exceptions occur...
    ... If the command is "buffer", ... but I get exceptions if the buffer file does ... procedure LoadCache(Const cacheName: String); forward; ... if (idx < Length(files)) then ...
    (alt.comp.lang.borland-delphi)
  • Re: some c# questions!! please send me the answer
    ... TryParse first to see if the string is a valid DateTime before doing ... In .NET 1.1 all you can do is Prase and catch any exceptions ... Boxing is creating a "reference" shell around a value object so that it ... each "int" and then adds those object wrappers to the ...
    (microsoft.public.dotnet.csharp.general)