Anwendung von try-catch

[Guest]

Hallo,

könnt ihr mir sagen welche der beiden Anwendung von try-catch-Blöcken richtig ist?

1.)
mit einem try-catch-Block werden immer nur die Zeilen in einer Methode bzw. einem Konstruktor umschlossen die diesen Block auch unbedingt benötigen.

2.)
mit einem try-catch-Block wird der gesamte Code der Methode bzw. des Konstruktors umschlossen auch wenn manche Zeilen den im catch-Block angegebenen Fehler garnicht werfen können. Das wird wegen der Übersichtlichkeit so gemacht, da so alle catch-Blöcke der Methode bzw. des Konstruktors gesammelt am Ende stehen.

 

[Guest]

Weder das eine, noch das andere kann als "die" Antwort gelten.

I.d.R. sind Folgeanweisungen vom Erfolg der vorangehenden Anweisungen abhängig. z.B. Scheitert das Öffnen einer Datei,
dann kann man sie auch nicht lesen und mit dem Gelesenen etwas anstellen.
So gesehen, gehören die Anweisungen alle in einen Block.

Du musst dir immer überlegen, wie du auf einen Fehler reagierst, wenn überhaupt, bzw. ob eine Fehlerbehandlung möglich/nötig ist.

 

[NTB]

Ja können wir.
Könnten wir. Machen wir aber erstmal so nicht.

Was meinst Du denn? Und warum meinst Du das?

 

[Guest]

Was bis du denn für ein Vollidiot NTB

 

[Guest]

Meine Frage bezieht sich auf das Beispiel unten. Die letzte Zeile des static-Konstruktors darf ja nicht in den try-catch-Block, weil sonst nicht sichergestellt ist, das HOST initialisiert wird.

PS: Das mit dem Vollidiot war ein anderer Gast... naja so ganz unrecht hat dieser damit ja nicht ;-)

class test
{
   private static final String HOST;

   static
   {
    
       Properties properties = new Properties();
       
       try
         {
         properties.load(new FileInputStream("C:\\ds.properties"));
         }
       catch(Exception e)
      {
         
      }
         
       HOST = properties.getProperty("host");   
   }
}

 

[SebiB90]

aber wenn nichts geladen werden kann. existiert auch der Key nicht.
also wird HOST auch nichts zugewiesen.
ich würde die zuweisung auch in den try block rein packen und im catch block nen default wert für HOST setzen

 

[Guest]

Meine Frage bezieht sich auf das Beispiel unten. Die letzte Zeile des static-Konstruktors darf ja nicht in den try-catch-Block, weil sonst nicht sichergestellt ist, das HOST initialisiert wird.

Was passiert in diesem Block, wenn das lesen der Property-Datei scheitert? Eine Initialisierung in dieser Form macht
absolut keinen Sinn bzw. ist nicht sicher.

Kann es sein, dass es irgendwie mit dem hier "Statischem Konstruktor Parameter übergeben" zusammenhängt?
Wenn ja, dann lass es mit den Statics. Verwende statt dessen eine Bean, die im Application-Scope initialisiert wird
oder noch besser Kontextparameter in web.xml.

z.B.

<context-param>
   <param-name>host</param-name>
   <param-value>localhost</param-value>
</context-param>

in deinem JSP Code kannst du dann mit

String host = application.getInitParameter("host");

darauf zugreifen.

PS: Das mit dem Vollidiot war ein anderer Gast... naja so ganz unrecht hat dieser damit ja nicht ;-)

Yepp, ein ganz anderer. Ich war's auch nicht. Ich bin derjenige, der die erste Antwort geschrieben hat.

 

[Guest]

Genau nach diesem Tipp hab ich gesucht

So werd ich's machen...

 

[Illuvatar]

PS: Das mit dem Vollidiot war ein anderer Gast...

Sorry, aber das stimmt leider nicht. Und das Verhalten find ich jetzt auch nich besser als NTBs. Nur so nebenbei.

 

[NTB]

Hrhrhrhr, eigentlich wollte ich gar nichts dazu schreiben, aber das find ich ja doch lustig Schon doof, wenn die IP geloggt wird *g*
Dann doch noch zur Erklärung: Für mich klang das absolut wie eine Hausaufgabenfragestellung, daher auch ganz nach Protokoll keine vernünftige Antwort. Über die Art und Weise kann man nun streiten, ich mach das nunmal sarkastisch.
Hätte er die Frage gleich so ausführlich gestellt wie in Posting #5, hätte ich gerne geantwortet.

 

[maki]

Gast hier, Gast da... wenn jemand schon mehrere Fragen hier stellt, kann er sich auch einen Account anlegen, hilft dem Forum, und das Forum hilft ja schliesslich auch Leuten.

Nebenbei bemerkt, warum sollte eine JNDI oder Namingexception besser sein als eine FileException?

Das solche Dinge in den Deployment Diskriptor gehören ist klar, aber die Exceptions nehmen sich nicht viel