---

Jeg forsøger at lære mig Java ved at læse sprogdefinitionen, men tror
jeg har overset noget. Ifølge sprogdefinitionen bør dette ikke være
tilladt uden en "throws Exception":

public class Foo {
public static void foo(boolean b) {
try {
System.out.println(b);
if( b ) throw new Exception();
} finally { return ; }
}
public static void main(String[] args) {
foo(true); foo(false);
}
}

men både Eclipse JDK og Jikes oversætter det glad og fro, og det er
naturligvis også ufarligt på køretidspunktet. Så vidt jeg kan læse
sprogdefinitionen (har tjekket version 1.0, afsnit 14.16, og version
3.0, afsnit 14.18) ser ud som om det kun er en udtrykkelig catch (og
altså ikke en divergerende finally) som kan skygge for et kast? Især
får det mig til at tvivle på min læsning at Jikes's eget mission
statement påstår at de følger det officielle sprog strengt. Men hvad
har jeg overset?

--
Henning Makholm "He who joyfully eats soup has already earned
my contempt. He has been given teeth by mistake,
since for him the intestines would fully suffice."

---

Scripsit Henning Makholm <henning@makholm.net>

> men både Eclipse JDK og Jikes oversætter det glad og fro,

Og det gør Sun JDK 1.5 for den sags skyld også.

--
Henning Makholm "Fætter Frode fisker fredag formiddag."

---

Henning Makholm wrote:
> Jeg forsøger at lære mig Java ved at læse sprogdefinitionen, men tror
> jeg har overset noget. Ifølge sprogdefinitionen bør dette ikke være
> tilladt uden en "throws Exception":

Jeg tror at det er fordi du tillader dig noget så skævt som at have return
inden i finally. Dette er det eneste exit punkt for metoden, og derfor ville
det ikke give mening at lave en throws Exception, da dette aldrig sker.

Fjern return fra finally blokken, så arter den sig som du forventer.

I øvrigt advarer min Eclipse "finally block does not complete normally",
hvilket jo er det centrale i problemstillingen.

/Johnnie

---

Scripsit Johnnie Hougaard Nielsen <sfromis@post1.tele.dk>
> Henning Makholm wrote:

>> Jeg forsøger at lære mig Java ved at læse sprogdefinitionen, men tror
>> jeg har overset noget. Ifølge sprogdefinitionen bør dette ikke være
>> tilladt uden en "throws Exception":

> Jeg tror at det er fordi du tillader dig noget så skævt som at have return
> inden i finally. Dette er det eneste exit punkt for metoden, og derfor ville
> det ikke give mening at lave en throws Exception, da dette aldrig sker.

Spørgsmålet er ikke om det giver mening, men om oversætteren ifølge
sprogdefinitionen skal afvise koden som ulovlig eller ej.

> Fjern return fra finally blokken, så arter den sig som du forventer.

Den arter sig ganske som jeg forventer, altså lige bortset fra at jeg
ikke forstår _hvorfor_ jeg får lov til at skrive sådan.

> I øvrigt advarer min Eclipse "finally block does not complete normally",
> hvilket jo er det centrale i problemstillingen.

Javist, det gør min også. Men det er kun en advarsel, ikke en fejl.
(Og sprogdefinitionen giver så vidt jeg kan se heller ikke hjemmel
til at lade det være en fejl).

--
Henning Makholm "It's just as meaningful to say that our
ancestors could easily have been very much like squirrels."

---

Henning Makholm wrote:
> Spørgsmålet er ikke om det giver mening, men om oversætteren ifølge
> sprogdefinitionen skal afvise koden som ulovlig eller ej.

Jeg har ikke nærlæst JLS, men vil mene at denne er fejlbehæftet hvis den
kræver en throws i dit eksempel. Men det tvivler på at den gør det.

Mit pointe er at når du synes at compileren skulle klage over "manglede"
throws, så bør det være fordi du læser JLS uden at huske på hvad din kode
gør. Altså *altid* går i return.

> Den arter sig ganske som jeg forventer, altså lige bortset fra at jeg
> ikke forstår _hvorfor_ jeg får lov til at skrive sådan.

Fordi return i finally blokken er det _eneste_ exit punkt fra metoden.
Det vil sige at metoden _aldrig_ kan forlades med den Exception som du
kaster, for denne kører jo også ind i finally blokken. Og return'en
afslutter metoden, hvilket vil sige at din exception bliver slugt uden
så meget som et bøvs.

Der ville være grundlag for at fejlmelde compileren hvis den klagede over
manglende throws/catch i dit eksempel. Den er heldigvis smart nok til at
gennemskue at metoden kun kan forlades gennem return statementet.

> Javist, det gør min også. Men det er kun en advarsel, ikke en fejl.
> (Og sprogdefinitionen giver så vidt jeg kan se heller ikke hjemmel
> til at lade det være en fejl).

Det lyder rigigt. Eclipse kan dog customiseret til at lade rappet over
nallerne være rødt i stedet for gult.

---

Scripsit Johnnie Hougaard Nielsen <sfromis@post1.tele.dk>
> Henning Makholm wrote:

>> Spørgsmålet er ikke om det giver mening, men om oversætteren ifølge
>> sprogdefinitionen skal afvise koden som ulovlig eller ej.

> Jeg har ikke nærlæst JLS,

På hvilket grundlag udtaler du dig så?

> Mit pointe er at når du synes at compileren skulle klage over "manglede"
> throws, så bør det være fordi du læser JLS uden at huske på hvad din kode
> gør. Altså *altid* går i return.

Jeg ved udmærket hvad min kode gør, men det ændrer ikke på hvad der
står og ikke står i sprogdefinitionen.

> Fordi return i finally blokken er det _eneste_ exit punkt fra metoden.
> Det vil sige at metoden _aldrig_ kan forlades med den Exception som du
> kaster, for denne kører jo også ind i finally blokken.

Det er vi ikke uenige om. Men det ændrer ikke på de betingelser en
oversætter skal rapportere fejl under. Statisk korrekthed er i
princippet uafhængigt af hvad der sker på køretiden (bortset fra i det
omfang de statiske betingelser er _designet_ til at have nogeet med
det at gøre).

--
Henning Makholm "Al lykken er i ét ord: Overvægtig!"

---

Den Thu, 03 Aug 2006 18:36:58 +0200. skrev Henning Makholm:

> 3.0, afsnit 14.18) ser ud som om det kun er en udtrykkelig catch (og
> altså ikke en divergerende finally) som kan skygge for et kast? Især
> får det mig til at tvivle på min læsning at Jikes's eget mission
> statement påstår at de følger det officielle sprog strengt. Men hvad
> har jeg overset?
Jeg er ikke sikker, men skyldes det ikke, at du instantierer klassen fra
en statisk instans?

hilsen,
Michael.

---

Scripsit Michael Rasmussen <mir@miras.org>
> Den Thu, 03 Aug 2006 18:36:58 +0200. skrev Henning Makholm:

>> 3.0, afsnit 14.18) ser ud som om det kun er en udtrykkelig catch (og
>> altså ikke en divergerende finally) som kan skygge for et kast? Især
>> får det mig til at tvivle på min læsning at Jikes's eget mission
>> statement påstår at de følger det officielle sprog strengt. Men hvad
>> har jeg overset?

> Jeg er ikke sikker, men skyldes det ikke, at du instantierer klassen fra
> en statisk instans?

Jeg instantierer slet ikke klassen. Men hvad skulle det i øvrigt ændre?

--
Henning Makholm "So you're nostalgic for a whole two-month period?"

---

Henning Makholm <henning@makholm.net> writes:

> men både Eclipse JDK og Jikes oversætter det glad og fro, og det er

Jikes er kørt bagud af ræset. Eclipse's oversætter er den nyeste.

Hvis du vil vide om Sun kan lide det, så oversæt den med javac.
--
Thorbjørn Ravn Andersen

---

Den Thu, 03 Aug 2006 20:45:15 +0200. skrev Thorbjørn Ravn Andersen:

> Hvis du vil vide om Sun kan lide det, så oversæt den med javac.
Nu vi har det på banen, så undrer det mig, at Sun med j2se ikke
automatisk sætter option -Xlint, da det i dokumentation fremgår, at det
er den anbefalede fremgangsmåde?

Sættes denne på Hennings eksempel får man også ganske rigtigt, som
også nævnt andet steds, følgende warning:
Foo.java:6: warning: [finally] finally clause cannot complete normally
} finally { return ; }
^
1 warning

---

Michael Rasmussen <mir@miras.org> writes:

> > Hvis du vil vide om Sun kan lide det, så oversæt den med javac.
> Nu vi har det på banen, så undrer det mig, at Sun med j2se ikke
> automatisk sætter option -Xlint, da det i dokumentation fremgår, at det
> er den anbefalede fremgangsmåde?

Formentlig bagudkompatabilitet. Men hvorfor Sun gør som de gør, er
vist ikke noget man skal bruge for meget krudt på at tænke over.

Eclipse compileren er så vidt jeg kan se stille og roligt ved at
forskube alle andre java compilere udenfor Sun.

>
> Sættes denne på Hennings eksempel får man også ganske rigtigt, som
> også nævnt andet steds, følgende warning:
> Foo.java:6: warning: [finally] finally clause cannot complete normally
> } finally { return ; }

Da det blev nævnt har jeg faktisk set det et sted før, Det er også
ligemeget for det burde være forbudt at kode sådan :)

--
Thorbjørn Ravn Andersen

---

Scripsit nospam0000@gmail.com (Thorbjørn Ravn Andersen)
> Henning Makholm <henning@makholm.net> writes:

>> men både Eclipse JDK og Jikes oversætter det glad og fro, og det er

> Jikes er kørt bagud af ræset. Eclipse's oversætter er den nyeste.

Eksperimentet gik mere ud på at opklare om det var en Eclipse-specifik
udvidelse der gør at det bliver accepteret.

> Hvis du vil vide om Sun kan lide det, så oversæt den med javac.

Det gjorde jeg også bagefter. Suns oversætter kan også godt lide det.
Det gør det desto underligere at oversætteren ifølge samtlige udgaver
af _The Java Language Specification_ *ikke* burde kunne lide det.

Med mindre altså jeg har overset noget i specifikationen, men jeg kan
ikke se hvad det skulle være.


Men gcj kan _ikke_ lide det, har jeg nu også fundet ud af.

--
Henning Makholm "Amanda, I'm a mad scientist!
Testing crazy things on myself and those
who are close to me is my job. It's what I do!"

---

Henning Makholm wrote:
> Men gcj kan _ikke_ lide det, har jeg nu også fundet ud af.

Fejlmeld gcj.

---

Henning Makholm <henning@makholm.net> writes:

> Det gør det desto underligere at oversætteren ifølge samtlige udgaver
> af _The Java Language Specification_ *ikke* burde kunne lide det.

Andre har påpeget at din return inde i finally-delen, kaster alt dette
til side.

Du er ude i et patologisk tilfælde. Jeg må indrømme at jeg ikke kan
forstå hvorfor man overhovedet tillader at return må findes i en
finally.

Men hvis du kommer ud af din finally og lader metoden afslutte
normalt, så kommer hele "throws"-møllen i aktion.

Jeg plejer normalt i testprogrammer at lade main throw'e en
Exception. Så kan programmerne i hvert fald køre, go så kan man stte
mere til bagefter.
--
Thorbjørn Ravn Andersen

---

Scripsit Johnnie Hougaard Nielsen <sfromis@post1.tele.dk>
> Henning Makholm wrote:

>> Men gcj kan _ikke_ lide det, har jeg nu også fundet ud af.

> Fejlmeld gcj.

Jeg kan ikke finde et argumet i JLS for at koden er korrekt Java, så
hvad skulle jeg skrive i min fejlmelding?

--
Henning Makholm "Hele toget raslede imens Sjælland fór forbi."

---

Scripsit nospam0000@gmail.com (Thorbjørn Ravn Andersen)
> Henning Makholm <henning@makholm.net> writes:

>> Det gør det desto underligere at oversætteren ifølge samtlige udgaver
>> af _The Java Language Specification_ *ikke* burde kunne lide det.

> Andre har påpeget at din return inde i finally-delen, kaster alt dette
> til side.

Hm... JLS synes at være lidt inkonsistent. I tredje udgave angiver
afsnit 14.20 en korrekt betingelse for hvornår "a try statement can
throw an exception type E" som også omtaler hvorvidt finally-delen kan
terminere normalt ... men denne betingelse bliver der ikke henvist til
fra afsnit 14.18, som tværtimod skriver:

| .. at least one of the following three conditions must be true, or a
| compile-time error occurs:
| * The exception is not a checked exception [...]
| * The throw statement i contained in the try block of a try
| statement and the type of the Expression is assignable to the
| type of at least one catch clause [...]
| * The throw statement is contained in a method or constructor
| and the type of the Expression is assignable to at least one
| type listed in the throws clause of the declaration.

Ingen af de tre betingelser synes at være opfyldt i min kodestump.

> Du er ude i et patologisk tilfælde.

Javist. Det er dem der sætter grænserne for sproget.

Måske burde jeg gå videre i comp.lang.java (eller hvad den nu hedder).

--
Henning Makholm "I ... I have to return some videos."

---

Henning Makholm <henning@makholm.net> writes:

> Hm... JLS synes at være lidt inkonsistent. I tredje udgave angiver
> afsnit 14.20 en korrekt betingelse for hvornår "a try statement can
> throw an exception type E" som også omtaler hvorvidt finally-delen kan
> terminere normalt ... men denne betingelse bliver der ikke henvist til
> fra afsnit 14.18, som tværtimod skriver:

Jeg slog op i anden udgave (den gav Google mig) hvor afsnit 14.19.2
omhandler netop try-catch-finally.

Hvis try smider en exception V som skal boble op og finally blokken
afslutter brat (her med en return) afsluttes hele try-blokken brat
"and the throw of value V is discarded and forgotten".

> Måske burde jeg gå videre i comp.lang.java (eller hvad den nu hedder).

Nejda. Ovenstående burde være begrundelse nok til en fejlmelding.
--
Thorbjørn Ravn Andersen

---

Henning Makholm <henning@makholm.net> writes:

> Hm... JLS synes at være lidt inkonsistent. I tredje udgave angiver
> afsnit 14.20 en korrekt betingelse for hvornår "a try statement can
> throw an exception type E" som også omtaler hvorvidt finally-delen kan
> terminere normalt ... men denne betingelse bliver der ikke henvist til
> fra afsnit 14.18, som tværtimod skriver:
....
> Ingen af de tre betingelser synes at være opfyldt i min kodestump.

Det giver jeg dig ret i. De mangler specialtilfældet hvor en finally-
blok blokkerer for exception-propageringen.

De hinter til det lidt længere nede:
"If there are any enclosing try statements (§14.20) whose try blocks
contain the throw statement, then any finally clauses of those try
statements are executed as control is transferred outward, until the
thrown value is caught. Note that abrupt completion of a finally
clause can disrupt the transfer of control initiated by a throw
statement."
og i 11.2.2 beskriver de, meget lig 14.20, sådan en try-finally som
ikke smidende en exception.

Det ændrer ikke ved at de i 14.18 siger, ganske utvetydigt, at
programmet skal give en compile-fejl. Jeg vil sige at fejlen er
i JLS'en, ikke i programmet.

Med 11.2.2 og 14.20 mod 14.18 er der flertal for at dit program skal
compile :)

> Måske burde jeg gå videre i comp.lang.java (eller hvad den nu hedder).

"comp.lang.java.programmer" er nok den bedste. "comp.lang.java" findes
svjv ikke.

/L
--
Lasse Reichstein Nielsen - lrn@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

---

Henning Makholm <henning@makholm.net> writes:

> Jeg forsøger at lære mig Java ved at læse sprogdefinitionen, men tror
> jeg har overset noget. Ifølge sprogdefinitionen bør dette ikke være
> tilladt uden en "throws Exception":

Det jeg kan finde i JLS 3 (Java 5 spec'en) er sektion 11.2.2 (Exception
Analysis of Statements). Den siger, bl.a.:
"A try statement can throw an exception type E iff either:
* The try block can throw E and E is not assignable to any catch
parameter of the try statement and either no finally block is
present or the finally block can complete normally; or
..."

Det er den case der nærmest matcher dit program (de to andre har
exception'en opstående i catch- eller finally-blokkene). Du smider
exceptionen i try-blokken, der er ingen catch-exception der kan fange
den, og finally-blokken findes, men(!) din finally-blok kan *ikke*
"complete normally" (defineret sektion 14.1), da en return er en
"abrupt completion".

Altså, din try-statement kan ikke smide en exception af nogen type,
fordi den har en finally-blok der "compltes abruptly" på en anden måde
end at smide en exception.

> Men hvad har jeg overset?

"complete normally" :)

/L
--
Lasse Reichstein Nielsen - lrn@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

---

Scripsit Lasse Reichstein Nielsen <lrn@hotpop.com>
> Henning Makholm <henning@makholm.net> writes:

>> Jeg forsøger at lære mig Java ved at læse sprogdefinitionen, men tror
>> jeg har overset noget. Ifølge sprogdefinitionen bør dette ikke være
>> tilladt uden en "throws Exception":

> Det jeg kan finde i JLS 3 (Java 5 spec'en) er sektion 11.2.2 (Exception
> Analysis of Statements). Den siger, bl.a.:

Ja, den forklaring er god nok. Men jeg kan ikke finde noget der siger
at den kan _ophæve_ den fejl som throw-sætningen burde give i henhold
til den udtrykkelige specifikation i afsnit 14.18.

>> Men hvad har jeg overset?

> "complete normally" :)

Nej, for det udtryk findes ikke i 14.18.

--
Henning Makholm "Anything you can discover we
would be most happy to review."