---

Hej gruppe.

Jeg har nu sidet og læst lidt på en side jeg lige har fået anbefalet her
igruppen. Der er der nogle:

try{...}
catch (final Exception e) {...}

Jeg har aldrig set at man kan definere en Exception som final. Er alle
Exceptions final? Er der nogen fordel i at definere dem som final?

Det skal lige siges at der er tal om f.eks. IOException &
MalformedURLException, og ikke den generelle Exception, jeg ved dog ikke om
det gør nogen foskel for spøgsmålet.

The MaXx

---

The MaXx wrote:

> Jeg har aldrig set at man kan definere en Exception som final. Er alle
> Exceptions final? Er der nogen fordel i at definere dem som final?

final benyttes til at fortælle at et givent objekt ikke kan yderligere
overstyres, således at compileren véd at dens metodereferencer ikke kan
ændre sig, og derfor angives direkte uden opslag i det faktiske objekt.

Fx er String defineret med mange "final" for at udnytte netop dette, og
derved sætte hastigheden op.

Hvorfor i alverden der er en final på _den_ plads, er ret svært at sige,
med mindre hastigheden er kritisk.


--
Thorbjørn Ravn Andersen "...plus...Tubular Bells!"
http://bigfoot.com/~thunderbear

---

> Hvorfor i alverden der er en final på _den_ plads, er ret svært at sige,
> med mindre hastigheden er kritisk.

Ja nemlig.
Jeg ved godt hvad final er, og jeg bruger det tit, men jeg vidste bare ikke
en Exception kunne declareres som final.
Man skulle egentlig tro at den var det per default, men så burde compileren
da gøre opmærksom på at man ikke behøver at bruge det.

Stadig et uløst mysterium...

The MaXx

---

"Thorbjørn Ravn Andersen" <thunderbear@bigfoot.com> skrev i en meddelelse
news:3B269888.FBAE8011@bigfoot.com...
> The MaXx wrote:
>
> > Jeg har aldrig set at man kan definere en Exception som final. Er alle
> > Exceptions final? Er der nogen fordel i at definere dem som final?
>
> final benyttes til at fortælle at et givent objekt ikke kan yderligere
> overstyres, således at compileren véd at dens metodereferencer ikke kan
> ændre sig, og derfor angives direkte uden opslag i det faktiske objekt.
>
> Fx er String defineret med mange "final" for at udnytte netop dette, og
> derved sætte hastigheden op.
>
> Hvorfor i alverden der er en final på _den_ plads, er ret svært at sige,
> med mindre hastigheden er kritisk.

Det skal lige siges at ifølge flere eksperter på JavaOne, skal man ikke
bruge final til optimering, for HotSpot optimizeren er så god at den nok
selv skal opdage om noget er final eller ej, ved ganske enkelt og se om det
bliver ændret eller ej. Men man kan bruge final rent programmeringsmæssigt.

--
With many Thanks

Soren ' Disky ' Reinke ICQ #1413069 http://www.disky-design.dk/fishj
Remove IHSYD from email address when replying by email

---

> final benyttes til at fortælle at et givent objekt ikke kan yderligere
> overstyres, således at compileren véd at dens metodereferencer ikke kan
> ændre sig, og derfor angives direkte uden opslag i det faktiske objekt.

Den nyeste Hotspot laver selv den analyse runtime (altså finder klasser og
metoder der ikke overstyres), så med Hotspot er der ikke hastighedsmæssig
grund til at benytte final.

> Fx er String defineret med mange "final" for at udnytte netop dette, og
> derved sætte hastigheden op.

String er final af sikkerhedsmæssige årsager... Det er centralt at den er
immutable... Hvis man kunne nedarve fra String kunne man ændre ved den
egenskab...

Mvh. Madsie

---

The MaXx wrote:

> try{...}
> catch (final Exception e) {...}
>
> Jeg har aldrig set at man kan definere en Exception som final.

i ovenstående er (final Exception e) en "Formal parameter list", som
defineres her:
http://java.sun.com/docs/books/jls/second_edition/html/classes.doc.html#38698

- hvor final siges at være valgfri.

> Er alle Exceptions final?

Nej:

void f()
{
try
{
throw new Exception( );
}
catch( RuntimeException e )
{
// men hvorfor skulle man gøre nedenstående? - eller måske
// mere relevant: hvorfor beskytte imod det med final?
e = new Exception();
}
}


> Er der nogen fordel i at definere dem som final?

Jeg har fundet et eksempel frem, hvor final argumenter er krævet -
nemlig hvis de skal bruges af en klasse, som er defineret inde i en
metode:

static void f( final int n )
{
try
{
throw new Exception();
}
catch( final Exception e )
{
class A
{
A()
{
// e og n kan kun tilgås herfra, fordi de er    
    // erklæret final
System.out.println( n );
e.printStackTrace();
}
}
new A();
}
}

Udover ovenstående kan jeg dog ikke se den umiddelbare værdi i at
erklære argumenter som final - anyone?

Ulrik Magnusson

--
"hvorfor er det stadig tilladt at høre klassisk musik ?"
'Mickey'
Visit my home page: http://www.geocities.com/ulrikm

---

> // men hvorfor skulle man gøre nedenstående? - eller måske
> // mere relevant: hvorfor beskytte imod det med final?
> e = new Exception();

Jeg har engang i mellem lavet noget a la:

catch (ServletException e) {
if (e.getInitialException() != null)
e = e.getInitialException();
log.log(e);
}

Men hvorfor netop det skulle kunne forbydes kan jeg ikke helt se.

Forklaringen er nok, dels at catch blokken svarer til en metode, og
derfor får denne feature med. Dels kan det være fint, hvis man gerne vil
bruge sin Exception i en anonym inner class i catch blokken.

-dennis

---

The MaXx wrote:

> try{...}
> catch (final Exception e) {...}
>
> Jeg har aldrig set at man kan definere en Exception som final.

i ovenstående er (final Exception e) en "Formal parameter list", som
defineres her:
http://java.sun.com/docs/books/jls/second_edition/html/classes.doc.html#38698

- hvor final siges at være valgfri.

> Er alle Exceptions final?

Nej:

void f()
{
try
{
throw new Exception( );
}
catch( RuntimeException e )
{
// men hvorfor skulle man gøre nedenstående? - eller måske
// mere relevant: hvorfor beskytte imod det med final?
e = new Exception();
}
}


> Er der nogen fordel i at definere dem som final?

Jeg har fundet et eksempel frem, hvor final argumenter er krævet -
nemlig hvis de skal bruges af en klasse, som er defineret inde i en
metode:

static void f( final int n )
{
try
{
throw new Exception();
}
catch( final Exception e )
{
class A
{
A()
{
// e og n kan _kun_ tilgås herfra, fordi de er
    // erklæret final
System.out.println( n );
e.printStackTrace();
}
}
new A();
}
}

Udover ovenstående kan jeg dog ikke se den umiddelbare værdi i at
erklære argumenter som final - anyone?

Ulrik Magnusson

--
"hvorfor er det stadig tilladt at høre klassisk musik ?"
'Mickey'
Visit my home page: http://www.geocities.com/ulrikm

---

Du skal tænke at 'e' er en reference til et objekt der har typen Exception.
Hvad final udtrykker i dette tilfælde er at du ikke kan lade 'e' pege på andre
objekter. Du kan stadig bruge e.setMessage(....), 'e' kan blot ikke pege på
andre objekter.
Det er en fordel at bruge final idet det er en hjælp til compileren, men der
opnåes ikke særligt meget så hvis du finder det for mystisk kan du blot udelade
det.


Lars

"The MaXx" <themaxx@mail.dk> wrote in message
news:9g61k8$2i9$1@news.inet.tele.dk...
> Hej gruppe.
>
> Jeg har nu sidet og læst lidt på en side jeg lige har fået anbefalet her
> igruppen. Der er der nogle:
>
> try{...}
> catch (final Exception e) {...}
>
> Jeg har aldrig set at man kan definere en Exception som final. Er alle
> Exceptions final? Er der nogen fordel i at definere dem som final?
>
> Det skal lige siges at der er tal om f.eks. IOException &
> MalformedURLException, og ikke den generelle Exception, jeg ved dog ikke om
> det gør nogen foskel for spøgsmålet.
>
> The MaXx
>
>