Entwickler-Ecke :: Thema anzeigen - Java try..catch in Delphi übersetzen

Ruditschka - Fr 21.11.03 00:28
Titel: Java try..catch in Delphi übersetzen

Hallo zusammen!

Ich habe ein Problem beim übersetzen einer JAVA-Unit in eine Delphi-Unit.
Im Java-Quelltext stehen an einigen Stellen folgende try..catch-Konstrukte (zur besseren Verständlichkeit auch die umgebende Zeilen):

Quelltext

1:
2:
3:
4:
5:
6:
7:
8:

write(CTRL, 0x00);  // EPP-Control-Byte löschen
try {
  Thread.sleep(10);
}
catch (interruptedexception e) {
}
write(CTRL, 0x04);  // EPP-Reset-Bit setzen -> EPP reset
write(STAT, 0x00);  // EPP-Timeout löschen

Wer kann mir da weiterhelfen?
Wie die Kommentare schon vermuten lassen, handelt es sich um eine Init-Routine für die EPP-Schnittstelle.

Die JBuilder 9 Personal-Hilfe sagt dazu folgendes:
http://christophruediger.netfirms.com/Dateien/key_try.html
http://christophruediger.netfirms.com/Dateien/interruptedexception.html

Demnach müsste die try..catch-Anweisung so etwas wie try.. except sein. Interruptedexception ist dann wohl die Art der exception. Aber welche ist das in Delphi?
Der Code sollte auch unter Win XP laufen (also keinen direkten Zugriffe auf irgendwelche Adressen, wo evtl. Pointer lagern oder so etwas - oder mit ausreichend Kommentaren :wink: )

Besten Dank für die Hilfe!

Christoph

datensender - Fr 21.11.03 09:52

Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:

try {
    ...
    ...
} catch (ExceptionTyp1 e) {
    ...
} catch (ExceptionTyp2 e) {
    ...
} catch (ExceptionTyp3 e) {
    ...
} finally {
    // clean up
}

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:

try
  ...
  ...
except
  on E: ExceptionTyp1 do
  begin
    ...
  end;

  on E: ExceptionTyp2 do
  begin
    ...
  end;

  on E: ExceptionTyo3 do
  begin
    ...
  end;
end;

da Delphi nur ein Finally ODER ein Except akzeptiert (nicht beides
zusammen wie bei Java), muss man sich einwenig mit der "ExceptObject"-Funktion
behelfen, welche das ggw. Exception-Objekt (E, e) zurückgibt, allerdings
als TObject-Typ.

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:

try
  ...
  ...
finally
  // ein "clean up" ist dann hier auch vor der 
  // Fehlerbehandlung möglich
  ...

  // Fehler behandeln
  if (ExceptObject is ExceptionTyp1) then    // wen nil, is -> False
  begin
    ...
  end;

  if (ExceptObject is ExceptionTyp2) then    
  begin
    ...
  end;

  if (ExceptObject is ExceptionTyp3) then    
  begin
    ...
  end;
   
  // clean up
  ...
end;

Ruditschka hat folgendes geschrieben:

Interruptedexception ist dann wohl die Art der exception. Aber welche ist das in Delphi?

Diese Exception entsteht, wenn ein Thread z.B. auf die
Freigabe einer gesperrten Resource wartet (wait) oder auf andere Weise blockiert (in deinem Fall z.B. 10 ms lang schlafen), sich selbst in dem Zeitraum aber nicht auf einen Abbruch prüfen kann. Wenn dann irgendwo durch die Methode "interrupt" abgebrochen wird, wird diese
Exception geworfen und der Thread kann entsprechend darauf reagieren...

In Delphi lässt sich das nicht so einfach 1:1 übernehmen, da die Threads
dort anders implementiert sind...

Thread.Sleep() wirkt sich auf den aufrufenden Thread aus. d.h. dein Stück Code macht nichts anderes als 10 millisekunden zu warten um anschließend fortzufahren...
Falls dabei der Thread beim nichts-tun unterbrochen wird, springt er
in die Exceptionbehandlung, macht allerdings nichts (verschweigt
das Vorkommen) und fährt fort mit der Ausführung...

Je nachdem wieviel Mühe du dir geben willst, dürfte auch "Sleep(10);"
in Delphi reichen... kenne aber den restlichen Code nicht...
daher Angaben ohne Gewähr..

Ruditschka - So 23.11.03 00:09

Zuerst einmal Danke für die Antworten.

Die Prozedur (eine von mehreren) in der die Blöcke vorkommen ist diese:

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:
30:
31:
32:
33:
34:
35:
36:
37:
38:

const
  cSTAT = {Base +} 1;
  cCTRL = {Base +} 2;

{...}

(**
 * Grundlegende Initialisierung der EPP-Schnittstelle.
 *
 * Parameter:
 *   aPort: Port-Nr. der EPP-Schnittstelle (1=LPT1, 2=LPT2)
 *
 * Rückgabe:
 *   true/false: Init erfolgreich / nicht erfolgreich
 *)
function TEpp.Init(aPort: Byte): Boolean;
begin
  InitResult := false;
  try
    case aPort of
      1: Base := $378;
      2: Base := $278;
    else
      Base := 0;
    end;
    if (Base <> 0) then
      begin
      Write(cCTRL, $00);    // EPP-Control-Byte löschen
      // try..catch Block
        Sleep(10);
      Write(cCTRL, $04);    // EPP-Reset-Bit setzen -> EPP reset
      write(cSTAT, $00);    // EPP-Timeout löschen
      InitResult := true;
      end;
  finally
    Result := InitResult;
  end;
end;

Dies ist die Funktion, bei der ich mir noch unsicher bin. In den anderen Funktionen/Prozeduren wird nur auf einen I²C-Controller bzw. dessen Synchronisierung gewartet. Da nach dem try..catch Block sowieso eine Statusabfrage des Controllers kam, habe ich mich entschlossen einfach nur Sleep(10) zu nehmen und an den Anfang jeder Schleife ein Application.ProccessMessages zu setzen.

Evtl. kennt sich jemand genauer mit der EPP-Schnittstelle aus. Dies ist mein erstes Projekt damit. Bis jetzt habe ich den Port immer direkt angesprochen (SPP). Reicht in diesem Falle ein einfaches warten? Oder gibt die EPP-Schnittstelle irgendwelche Antwort, sobald sie resetet ist (Die dann vielleicht sogar noch eine Exception auslöst)?

Gruß
Christoph

Entwickler-Ecke.de based on phpBB
Copyright 2002 - 2011 by Tino Teuber, Copyright 2011 - 2025 by Christian Stelzmann Alle Rechte vorbehalten.
Alle Beiträge stammen von dritten Personen und dürfen geltendes Recht nicht verletzen.
Entwickler-Ecke und die zugehörigen Webseiten distanzieren sich ausdrücklich von Fremdinhalten jeglicher Art!