try catch optimering

lav dine metoder med en \'throws RemoteException\'

og lad den metode der kalder styre dine try & catch

Det er klart nemmere. Og vel også mere korrekt i dit tilfælde

Vis jeg forståår dig ret så mener du følgende ?:

minMetode()throws RemoteException
{

  try
  {
    String data = database.hentdata(string navn);
  }

}

Ok der ved undgår jeg at skrive catch hver gang.
Men jeg skal stadigvæk lave en try hver eneste gang jeg vil have adgang rit mit RemoteObjekt.
Vil nu gerne hver gang jeg skal have adgang tim mit Remote objekt kalde 1 metode der udfører alle mine try catch. Er det mon muligt

I har begge to fat i noget rigtigt. Men der er vel egentlig ikke noget endegyldigt svar.

Hvis du er bekymret over at have
try {
  statement;
} catch (RemoteException re) {}
try {
  nextStatement;
} catch (RemoteException re) {}

Så er det muligt at lægge begge statements ind i en samlet try-catch, måske for en hel metode.
try {
  statement;
  nextStatement;
} catch (RemoteException re) {}

Du kan også tage de logiske ting, der skal udføres over for dit remote objekt og pakke ind i en samlet metode, som så generelt kaster en RemoteException videre til en styrende klasse.

Du skal under alle omstændigheder gøre dig bevidst, hvordan du vil håndtere situationen, for hvad nu hvis det ikke kan lade sig gøre pga netværksproblemer etc.

Om du så kører en statement af gangen, eller fyrer et helt scenario, skal du spekulere i din nødplan.

try {
  doSomething();
} catch (RemoteException re {
  // how do we fallback in case of emergency
}

Hvis du har flere statements i et scenario, vil du ikke kunne pinpointe præcis, hvor problemet opstår, men sikre dig en alt eller intet løsning. Dvs. hvis du arbejder på nogle attributter inde i en klasse, og du udfører et remotekald, ændrer dine attributter, og laver et remotekald mere, skal du være bevidst om, at dine attributter muligvis er ændret, muligvis ikke, når der kommer en exception. Det imødegås typisk ved at gemme internt i lokale variable i metoden, indtil du har udført dit sidste remotekald, og derefter flytte data ind i attributterne.

Så.. Du kan se, du slipper nok ikke for at skulle håndtere det, men du har alligevel lidt råderum.

Der er flere forskellige måder at håndtere det på.

For det første kan du pakke det ind i en metode eller klasse.

Metodeversionen kunne se sådan ud:

private String hentMineData(String navn, SomeObject database) {
String data = null;
try
{
data = database.hentdata(string navn);
}
// din catch ser lidt underlig ud??
catch
{
RemoteException(re)
}
return data;
}

Hvis database og navn ikke er en lokale variable kan du spare argumenterne til metoden.
Ønsker du at håndtere Exceptions forskelligt i forskellige kald til metoden, kan du lave nogle objekter der ved hvordan det skal gøres, og så enten give dem med som argument eller lade en variabel referere til den aktuelle handler.

thomaz: det er nemlig helt korrekt du gør det på den måde.

Den metode som så kalde \'minMetode\'

f.eks:

....
minMetode()
....

skal så have en try/catch rundt om.

Så det bliver til:

try
{
  minMetode();
}
catch (RemoteException e)
{

}


Men hvis du inde i minMetode gerne vil have din try/catch, men laver noget mange gange som skal catches, så går følgende.

{
  String data;
  try
  {
    data = database.hentdata(string navn);
    LavNogetAndet
    data = database.hentdata(string navn);
    LavNogetAndet
    data = database.hentdata(string navn);
    LavNogetAndet
    data = database.hentdata(string navn);
    LavNogetAndet
    data = database.hentdata(string navn);
    LavNogetAndet
  }
  catch (RemoteException e)
  {
  }
}

Du kan sagtens fange 10 ting med en try/catch.

Det var da en utroligt dårlig ide. Så hvis en af kaldende smider en Exception så:
1) De efterfølgende kald udføres ikke, da vi er færdige med try blocken
2) Vi ved ikke hvilket kald der resulterede i en Exception.
3) Farvel OO.

delbing: det må du jo diskuterer med SUN, for de gør det selv i deres kode.

1. har du hørt om finally ???

2. det er korrekt

3. wrong

delbing:
Ah, afhængig lidt af, hvad der sker, kan minMetode sagtens isoleres som en transaktion, hvor kun atomiteten er interessant, og det betyder ikke nødvendigvis farvel OO.

1 og 2 er vi enige om, men kun den aktuelle use case kan afgøre om det har interesse.

Den konstruktion du nævner kan (og bør) selvfølgelig bruges til at _forhindre_ at resten af try blocken udføres hvis der kommer en Exception.

1. Jeg kan ikke se hvad finally kan bruges til her? Hvordan vil du få finally blocken til at udføre de kald du mangler?

3. Det er ren hacking at proppe en masse ting ind i samme try block fordi man ikke gider skriver try-catch blokke. En meget bedre model er at have et objekt (eller måske blot en metode) som henter dataen _og_ håndterer evt. Exceptions. En god OO model vil håndtere Exceptions tæt på der hvor de opstår, ikke bare delegere dem videre til andre objekter som ikke har noget med det at gøre. Jeg gider ikke i gang med en flame omkring OO design, men der hvor man laver \'data = database.hentdata()\' er man (i en god model) interesseret i at få og behandle data, ikke at håndtere Exceptions som handler om noget andet (som fx en RemoteException).

delbing: det er jo også derfor jeg siger man kan have mange exceptions gemt i en.

Og det er stadigvæk OO

Takker for alle svarerne, også selv om jeg næsten startede en \"religions\" krig :-)