Warum über Ausnahmeverarbeitung im J2EE -Projekt sprechen? Vielleicht wollen viele Java -Anfänger sagen: "Es ist nicht nur Ausnahmehandling, nur versuchen ... Fang ... endlich? Jeder weiß das!" Der Autor denkt auch so, wenn er Java zum ersten Mal lernt. Wie definiere ich die entsprechende Ausnahmeklasse in einem mehrschichtigen J2EE-Projekt? Wie gehe ich mit Ausnahmen in jeder Ebene im Projekt um? Wann wird die Ausnahme ausgelöst? Wann wird die Ausnahme aufgezeichnet? Wie zeichne ich Ausnahmen auf? Wann sollte ich die überprüfende Ausnahme in eine nicht überprüfte Ausnahme umwandeln und wann sollte ich die ungeprüfte Ausnahme in eine geprüfte Ausnahme umwandeln? Sollte die Ausnahme auf der Front-End-Seite präsentiert werden? Wie gestalte ich ein Ausnahmebereich? Diese Themen werden in diesem Artikel erörtert.
1. Java -Ausnahmehandling
In prozeduralen Programmiersprachen können wir bestimmen, ob die Methode normalerweise durch Rückgabe des Werts ausgeführt wird. In einem in C -Sprache geschriebenen Programm wird beispielsweise die Methode korrekt ausgeführt. Wenn der Fehler ausgeführt wird, wird 0 zurückgegeben. In einer von VB oder Delphi entwickelten Anwendung werden wir beim Benutzer ein Meldungsfeld angeben, wenn ein Fehler auftritt.
Wir können die Fehlerdetails nicht über den Rückgabewert der Methode erhalten. Dies kann daran liegen, dass die Methode von verschiedenen Programmierern verfasst wurde. Wenn derselbe Fehlertyp in verschiedenen Methoden auftritt, sind die zurückgegebenen Ergebnisse und Fehlerinformationen nicht konsistent.
Daher nimmt die Java -Sprache einen einheitlichen Ausnahmebehandlungsmechanismus an.
Was ist eine Ausnahme? Fang- und verarbeitbare Fehler, die zur Laufzeit auftreten.
In der Java -Sprache ist die Ausnahme die übergeordnete Klasse aller Ausnahmen. Jede Ausnahme wird auf die Ausnahmeklasse ausgedehnt. Die Ausnahme entspricht einem Fehlertyp. Wenn Sie einen neuen Fehlertyp definieren möchten, erweitern Sie eine neue Ausnahme -Unterklasse. Der Vorteil der Verwendung von Ausnahmen besteht darin, dass er den Quellcodespeicherort, der den Programmfehler verursacht, genau finden und detaillierte Fehlerinformationen erhalten.
Die Handhabung der Java -Ausnahme wird durch fünf Keywords implementiert, versuchen Sie es, schließlich zu fangen, zu werfen, zu werfen. Die spezifische Ausnahmeregelungsstruktur wird durch den Versuch implementiert. Der Try -Block speichert Java -Anweisungen, die möglicherweise Ausnahmen haben. Der Haken wird verwendet, um das Auftreten von Ausnahmen zu erfassen und die Ausnahmen zu behandeln. Der letzte Block wird verwendet, um unfreundliche Ressourcen im Programm zu löschen. Der letzte Block wird immer ausgeführt, wenn der Code, der nicht verwaltet, wie der Try -Block zurückgegeben wird.
Ein typischer Ausnahmebehandlungscode
public String getPassword (String userID) löst DataAccessException aus {String SQL = "Kennwort aus userInfo wob while (rs.Next ()) {password = rs.getString (1);} rs.close (); fehlgeschlagen! ", SQLEX);}} Kennwort zurückgeben;} Es ist ersichtlich, dass die Vorteile von Javas Ausnahmebehandlungsmechanismus:
Der Fehler wird einheitlich klassifiziert und durch Erweiterung der Ausnahmeklasse oder ihrer Unterklasse implementiert. Dies vermeidet, dass der gleiche Fehler in verschiedenen Methoden unterschiedliche Fehlermeldungen aufweist. Wenn der gleiche Fehler in verschiedenen Methoden auftritt, müssen Sie nur das gleiche Ausnahmebobjekt auswerfen.
Erhalten Sie detailliertere Fehlerinformationen. Durch Ausnahmeklassen können Fehlerinformationen für die Ausnahme gegeben werden, die für den Benutzer detaillierter und nützlicher ist. Einfach für Benutzer, Programme zu verfolgen und zu debuggen.
Trennen Sie das richtige Rückgabergebnis von der Fehlermeldung. Reduziert die Komplexität des Programms. Der Anrufer muss nicht mehr über das Rückgabeergebnis erfahren.
Zwingen Sie den Anrufer, Ausnahmen zu bewältigen, um die Qualität des Programms zu verbessern. Wenn eine Methodenerklärung eine Ausnahme ausführen muss, muss der Anrufer den Versuch verwenden. Fangblock, um die Ausnahme zu behandeln. Natürlich kann der Anrufer auch die Ausnahme ermöglichen, weiterhin in die obere Ebene geworfen zu werden.
2. Ausnahme oder ungeprüfte Ausnahme?
Java -Ausnahmen sind in zwei Kategorien unterteilt: Überprüfung der Ausnahme und deaktivierte Ausnahme. Alle Ausnahmen, die Java.lang.Exception erben, gehören zu überprüften Ausnahmen. Alle Ausnahmen, die Java.lang.RuntimeException erben, gehören zu ungeprüften Ausnahmen.
Wenn eine Methode eine Methode aufruft, die eine geprüfte Ausnahme ausführt, muss die Ausnahme durch den Versuch erfasst und verarbeitet oder abgezogen werden.
Schauen wir uns die Erklärung der Methode CreateState () der Verbindungsschnittstelle an.
öffentliche Erklärung CreateStatement () löst SQLEXception aus; SQLEXception ist eine geprüfte Ausnahme. Wenn die Kreaturenmethode aufgerufen wird, zwingt Java den Anrufer, die SQLEXception zu erfassen. public String getPassword (String userId) {try {... Anweisung s = con.CreateStatement (); oder
public String getPassword (String userID) löst SQLEXception {Anweisung s = con.CreateStatement ();} aus (Natürlich müssen Ressourcen wie Verbindung und Satement rechtzeitig geschlossen werden. Dies ist nur zu veranschaulichen, dass die geprüfte Ausnahme den Anrufer dazu zwingen muss, zu fangen oder weiter zu werfen.)
Die ungeprüfte Ausnahme wird auch als Laufzeitausnahme bezeichnet. Normalerweise gibt die RunTimeException eine Ausnahme an, die der Benutzer nicht wiederherstellen kann, z. B. die Unfähigkeit, eine Datenbankverbindung zu erhalten, die Unfähigkeit, eine Datei zu öffnen usw. Wenn der Anrufer jedoch nicht die ungeprüfte Ausnahme fängt, zwingt der Compiler Sie nicht dazu.
Beispielsweise ist ein Code, der Zeichen in Ganzzahlwerte umwandelt, wie folgt:
String str = "123"; int value = Integer.ParseInt (str);
Die Parseint -Methode -Signatur lautet:
public staticint parseint (String s) löst NumberFormatexception aus
Wenn die übergebenen Parameter nicht in die entsprechende Ganzzahl konvertiert werden können, wird eine NumberFormatexception geworfen. Da sich Numberformatexception bis zur RunTimeException erstreckt, ist dies eine ungeprüfte Ausnahme. Es ist also nicht erforderlich, sich zu versuchen ... Fangen Sie beim Aufrufen der Parseint -Methode
Weil Java den Anrufer nicht zwingt, die ungeprüfte Ausnahme zu fangen oder auszuwerfen. Programmierer werfen also immer gerne ungeprüfte Ausnahmen. Oder wenn eine neue Ausnahmeklasse benötigt wird, wird sie immer daran gewöhnt, sich von RunTimeException zu erstrecken. Wenn Sie diese Methoden aufrufen und keinen entsprechenden Fangblock gibt, lässt der Compiler Sie immer bestehen, und Sie müssen nicht verstehen, welche Ausnahme diese Methode auswirkt. Es scheint, als wäre dies eine gute Idee, aber dies ist von der wirklichen Absicht der Ausnahme von Java weg. Und es ist irreführend für den Programmierer, der Ihre Klasse anruft, da der Anrufer keine Ahnung hat, unter welchen Umständen er ausgenommen werden muss. Die geprüfte Ausnahme kann dem Anrufer klar mitteilen, welche Ausnahmen bei der Aufrufen dieser Klasse behandelt werden müssen. Wenn der Anrufer es nicht verarbeitet, fordert der Compiler auf und kann nicht kompilieren und bestehen. Wie man damit umgeht, liegt natürlich an dem Anrufer, sich zu entscheiden.
Java empfiehlt also, dass Personen überprüfte Ausnahmen in ihrem Anwendungscode verwenden sollten. Genau wie wir im vorherigen Abschnitt erwähnt haben, dass der Vorteil der Verwendung von Ausnahmen darin besteht, dass er den Anrufer zwingen kann, die generierten Ausnahmen zu verarbeiten. Überprüfte Ausnahmen werden in offiziellen Java -Dokumenten wie "Java Tutorial" als Standard verwendet.
Die Verwendung überprüfter Ausnahmen sollte bedeuten, dass es viele versuchen ... Fang in Ihrem Code. Nach dem Schreiben und Umgang mit immer mehr Versuch… Fangblöcke begannen sich endlich zu fragen, ob überprüfte Ausnahmen als Standard verwendet werden sollten.
Sogar Bruce Eckel, der Autor des berühmten "Denkens in Java", veränderte seine früheren Gedanken. Bruce Eckel befürwortet sich sogar für nicht kontrollierte Ausnahmen als Standardeinsatz. Und veröffentlichen Sie einen Artikel, um zu testen, ob die geprüfte Ausnahme von Java entfernt werden sollte. Bruce Eckel: "Wenn eine kleine Menge Code, überprüfte Ausnahmen zweifellos ein sehr elegantes Konzept sind und viele mögliche Fehler vermeiden. Die Erfahrung zeigt jedoch, dass das Ergebnis genau das Gegenteil für eine große Menge an Code ist."
Ausführliche Diskussionen über überprüfte Ausnahmen und nicht kontrollierte Ausnahmen finden Sie unter
Java Tutorial http://java.sun.com/docs/books/tutorial/essential/exceptions/runtime.html
Die Verwendung überprüfter Ausnahmen kann viele Probleme verursachen.
Überprüfte Ausnahme verursacht zu viel Versuch ... Catch Code
Es kann viele überprüfte Ausnahmen geben, die von Entwicklern wie SQLEXception nicht vernünftigerweise behandelt werden können. Aber die Entwickler müssen es versuchen ... fangen. Wenn Entwickler eine geprüfte Ausnahme nicht richtig ausführen können, drucken sie normalerweise einfach die Ausnahme aus oder tun nichts. Besonders für Anfänger sorgen zu viele überprüfte Ausnahmen, wenn er sich klopft.
Versuchen Sie {… Anweisung s = con.CreateStatement ();… catch (SQLEXception SQLEX) {sqlex.printstacktrace ();} oder
Versuchen Sie {... Anweisung S = con.CreateStatement (); Überprüfte Ausnahme verursacht viele schwer verständliche Codegenerierung
Wenn Entwickler eine geprüfte Ausnahme aufnehmen müssen, die sie nicht richtig bewältigen können, werden sie normalerweise zu einer neuen Ausnahme umpackt und dann geworfen. Dies bringt dem Programm keine Vorteile. Stattdessen erschwert es den Code später schwer zu verstehen.
Genau wie wir JDBC -Code verwenden, gibt es viel Versuch… Fang. Der wirklich nützliche Code ist im Versuch enthalten… Catch. Es schwierig macht, diese Methode zu verstehen
Überprüfte Ausnahme führt dazu
public void methoda () löst Ausnahme aus {… ..Throw neue Ausnahme ();} public void methodb () löst Ausnahme aus {try {methoda ();…} catch (exceptiona ex) {werfen neu ausnahmeb); Wir sehen, dass die Ausnahme in die Schicht für Schicht eingekapselt und abgezogen wird.
Überprüfte Ausnahme verursacht die Vermittlung der Schnittstellenmethode
Eine Methode auf einer Schnittstelle wurde von mehreren Klassen verwendet. Wenn diese Methode eine zusätzliche geprüfte Ausnahme hinzugefügt wird, müssen alle Codes, die diese Methode aufrufen, geändert werden.
Es ist ersichtlich, dass die oben genannten Probleme gezwungen sind, zu fangen und zu verarbeiten, da der Anrufer die geprüfte Ausnahme nicht richtig behandeln kann und dazu gezwungen ist, einzukapseln und dann neu zu wechseln. Dies ist sehr unpraktisch und bringt keine Vorteile. In diesem Fall werden normalerweise ungeprüfte Ausnahmen verwendet.
Die geprüfte Ausnahme ist nicht alles. Die geprüfte Ausnahme ist viel einfacher zu bedienen als der Fehlerrückgabewert der herkömmlichen Programmierung. Es ist viel besser sicherzustellen, dass Ausnahmen durch den Compiler korrekt behandelt werden, als nach dem Rückgabewert zu beurteilen.
Wenn eine Ausnahme tödlich ist, ist sie nicht wiederholbar. Oder der Anrufer fängt es ohne Nutzen an und nutze die ungeprüfte Ausnahme.
Wenn eine Ausnahme wiederhergestellt und vom Anrufer korrekt behandelt werden kann, verwenden Sie die geprüfte Ausnahme.
Bei der Verwendung einer nicht kontrollierten Ausnahme muss die nicht gelägte Ausnahme, die die Methode werfen kann, in der Methodenerklärung ausführlich beschrieben werden. Der Anrufer entscheidet, ob die ungeprüfte Ausnahme auffängt
Wann können Sie überprüfte Ausnahmen und wann nicht überprüfte Ausnahmen verwenden? Es gibt keinen absoluten Standard. Aber ich kann einige Vorschläge machen
Wenn alle Anrufer diese Ausnahme abwickeln müssen, kann der Anrufer den Betrieb wiederholen. oder die Ausnahme entspricht dem zweiten Rückgabewert der Methode. Verwenden Sie die überprüfte Ausnahme.
Diese Ausnahme kann nur von wenigen fortgeschrittenen Anrufern behandelt werden, und gewöhnliche Anrufer können sie nicht richtig behandeln. Verwenden Sie die ungeprüfte Ausnahme. Anrufer, die verarbeitet werden können, können eine erweiterte Verarbeitung durchführen, aber im Allgemeinen können Anrufer überhaupt nicht umgehen.
Diese Ausnahme ist ein sehr schwerwiegender Fehler, wie z. B. Datenbankverbindungsfehler, das Öffnen von Dateien usw. oder diese Ausnahmen hängen mit der externen Umgebung zusammen. Es ist nicht möglich, das Problem der Wiederholung zu lösen. Verwenden Sie die ungeprüfte Ausnahme. Denn sobald diese Ausnahme eintritt, kann der Anrufer überhaupt nicht umgehen.
Wenn es nicht sicher ist, verwenden Sie eine ungeprüfte Ausnahme. Und beschreiben Sie detailliert die Ausnahme, die ausgelöst werden kann, damit der Anrufer entscheiden kann, ob er damit umgehen soll.
3.. Entwerfen Sie eine neue Ausnahmeklasse
Überprüfen Sie beim Entwerfen einer neuen Ausnahmeklasse zunächst, ob diese Ausnahmeklasse wirklich benötigt wird. Versuchen Sie im Allgemeinen, keine neuen Ausnahmeklassen zu entwerfen, sondern auch Ausnahmeklassen zu verwenden, die bereits in Java existieren.
wie
IllegalArgumentException, nicht unterstützte OperationException
Egal, ob es sich um die neue Ausnahme, eine Chekced -Ausnahme oder eine ungeprüfte Ausnahme handelt. Wir alle müssen das Nistproblem von Ausnahmen berücksichtigen.
public void methoda () löst Ausnahme aus {... um neue Ausnahmen ();};} Methode Methoda Deklaration löst Ausnahme aus.
public void methodb () löst Ausnahme aus
Methodb Declaration wird Ausnahme machen. Wenn Methoda in der MethodB -Methode aufgerufen wird, kann Ausnahme nicht verarbeitet werden, sodass die Ausnahme weiterhin übergeben werden sollte. Eine Möglichkeit besteht darin, die Methode -Deklaration Ausnahme zu machen. Dies hat jedoch die Methodensignatur von MethodB geändert. Sobald sich geändert hat, müssen alle Methoden, die Methodb geändert werden, geändert werden.
Eine andere Möglichkeit besteht darin, Ausnahme in ExceptionB zu integrieren und dann zu werfen. Wenn wir Ausnahme in Ausnahme nicht in Verbindung bringen, verlieren wir die Root -Ausnahmeinformationen, sodass es unmöglich ist, die ursprüngliche Quelle der Ausnahme zu verfolgen.
public void methodb () löst Ausnahme aus {try {methoda (); ...} catch (exceptiona ex) {neue Ausnahme werfen (ex);}} Wie im obigen Code nistet ExceptionB eine Ausnahme. Wir werden vorerst "Ausnahme verursachte Ausnahme" bezeichnen, da Ausnahme eine Ausnahme verursacht. Dies verhindert, dass die Ausnahmeinformationen verloren gehen.
Wenn wir also eine neue Ausnahmeklasse definieren, müssen wir einen solchen Konstruktor bereitstellen, der verschachtelte Ausnahmen enthalten kann. Und es gibt ein privates Mitglied, das diese "Ursache Ausnahme" speichert.
öffentliche Klasse ExceptionB erweitert Ausnahme {private Throwable Cause; public ExceptionB (String msg, Throwable Ex) {Super (msg); Wenn wir die PrintStacktrace -Methode anrufen, müssen wir natürlich alle Informationen "Ausnahmebeding" gleichzeitig ausdrucken. Daher müssen wir die PrintStacktrace -Methode überschreiben, um alle Ausnahmestapelspuren anzuzeigen. Enthält Stapelspuren verschachtelter Ausnahmen.
public void printStacktrace (printStrean ps) {if (cause == null) {Super.printstacktrace (ps);} else {ps.println (this); cause.printstacktrace (ps);}} Eine vollständige Unterstützung für verschachtelte Checked Exception Class -Quellcode ist wie folgt. Nennen wir es hier vorerst NestedException
public nestedException erweitert die Ausnahme {private Throwable Cause; public nestedException (String msg) {Super (msg);} public nestexception (String msg, Throwable Ex) {Super (msg); this.cause super.getMessage (); Turbable cause = getCause (); if (cause! = null) {message = message + "; verschachtelte Ausnahme lautet" + cause;} return message;} public void printStacktrace (printstream ps) {if (getCause == null) {Super.printstacktrace (ps);} else {ps.println (this); getCause (). printstacktrace (ps);}} public void printStacktrace (Printwrite pw) {if (getCause () == null) {super.printstacktrace (pw);} else {pw.println (this); getCause (). printstacktrace (pw);}} public void printStacktrace () {printStacktrace (System.Eror);}}}}}}}}}Außerdem müssen Sie eine ungeprüfte Ausnahmeklasse wie oben entwerfen. Es muss nur RunTimeException erben.
4.. Wie man Ausnahmen protokolliert
Als großes Anwendungssystem sind Protokolldateien erforderlich, um den Betrieb des Systems aufzuzeichnen, um die Verfolgung und Aufzeichnung des Betriebs des Systems zu erleichtern. Ausnahmen, die im System auftreten, müssen natürlich im Protokollsystem aufgezeichnet werden.
public String getPassword (String userID) löst NoSuchUseRexception aus {userInfo user = userDao.queryUserById (userId); if (user == null) {logger.info ("Die Benutzerinformationen können nicht gefunden werden, userID ="+userID); neue NoSuchuserexception ("Die Benutzerinformationen, die nicht gefunden wurden, userId = userId = userId); user.getPassword ();}} public void sendUserPassword (String userId) löst Ausnahme aus {userInfo user = null; try {user = getPassword (userId); //… ..Sendmail (); //} catch (NoSuchUsexception ex) (logger.ErrOR ("diese Benutzerinformationen können nicht gefunden werden:"+teufr. Wir haben festgestellt, dass ein Fehler zweimal angemeldet wurde. Bei der Herkunft des Fehlers zeichnen wir nur auf der Info -Ebene auf. In der SendUserPassword -Methode zeichnen wir auch die gesamten Ausnahmeinformationen auf.
Der Autor hat unabhängig von 3721 viele Projekte auf diese Weise aufgenommen, und die gesamte Ausnahme wird nur bei der Begegnung einer Ausnahme aufgezeichnet. Wenn eine Ausnahme kontinuierlich verkapselt und mehrmals geworfen wird, wird sie mehrmals aufgezeichnet. Wo sollte die Ausnahme aufgezeichnet werden?
Die Ausnahme sollte am ersten Ort aufgezeichnet werden!
Wenn Sie eine Ausnahme aufnehmen müssen, die nicht richtig behandelt werden kann, verkapulieren Sie sie einfach in eine andere Ausnahme und werfen Sie sie hoch. Es ist nicht erforderlich, die aufgezeichnete Ausnahme erneut aufzunehmen.
Wenn eine Ausnahme erfasst wird, kann diese Ausnahme behandelt werden. Es müssen keine Ausnahmen aufgezeichnet werden
public date getDate (String str) {Datum applydate = null; SimpleDateFormat format = new SimpleDateFormat ("mm/dd/yyyy"); try {applydate = format.parse (applyDateStr);} catch (ParseException ex) {// Warum, wenn das Format falsch ist, kehren}} apply;}}}}},} Wenn eine nicht aufgezeichnete Ausnahme oder eine externe Systemausnahme erfasst wird, sollten die Details der Ausnahme aufgezeichnet werden.
Try {… String SQL = ”SELECT * von userInfo”; Anweisung S = con.CreateStatement (); Wo man Ausnahmeinformationen aufzeichnet und wie man Ausnahmeinformationen aufzeichnet, kann eine Meinungsbeziehung sein. Einige Systeme lassen sogar Ausnahmen für Ausnahmeklassen aufzeichnen. Wenn ein neues Ausnahmeobjekt generiert wird, werden die Ausnahmeinformationen automatisch aufgezeichnet.
öffentliche Klasse BusinessException erweitert die Ausnahme {private void logTrace () {StringBuffer Buffer = new StringBuffer (); Buffer.Append ("Geschäftsfehler in der Klasse:"); Buffer.Append (getClassName ()); Buffer.Append (", Methode:"); Buffer.append (getMethodname ();); "); Buffer.Append (this.getMessage ()); logger.Error (buffer.toString ());} public BusinessException (String S) {Super (s); Race ();}; Dies scheint sehr wunderbar zu sein, aber es wird unweigerlich dazu führen, dass die Ausnahme wiederholt aufgezeichnet wird. Gleichzeitig verstößt es gegen das "Prinzip der Verteilung der Verantwortlichkeiten der Klassen" und ist ein schlechtes Design. Das Aufzeichnen von Ausnahmen gehört nicht zum Verhalten der Ausnahmeklassen, und die Aufzeichnung von Ausnahmen sollte von einem speziellen Protokollierungssystem durchgeführt werden. Und die abnormalen Aufzeichnungsinformationen ändert sich ständig. Wir erfassen Ausnahmen, die umfangreichere Informationen geben sollten. Dies hilft uns, die Hauptursache des Problems zu finden, die auf Ausnahmeinformationen basieren, um das Problem zu lösen.
Obwohl wir viel über die Aufzeichnung von Ausnahmen besprochen haben, macht zu viel Betonung auf diese Entwickler verwirrter. Eine gute Möglichkeit besteht darin, ein Ausnahmebehandlung -Framework für das System bereitzustellen. Das Framework entscheidet, ob Ausnahmen aufgezeichnet werden und wie Ausnahmen aufgezeichnet werden sollen. Es liegt nicht an gewöhnlichen Programmierern, sich zu entscheiden. Aber es ist vorteilhaft, etwas zu wissen.
5. Ausnahmehandling im J2EE -Projekt
Gegenwärtig sind J2EE -Projekte im Allgemeinen logisch in mehrere Ebenen unterteilt. Die klassischen sind in drei Ebenen unterteilt: Präsentationsschicht, Geschäftsschicht und Integrationsschicht (einschließlich Datenbankzugriff und externer Systemzugriff).
Das J2EE -Projekt hat seine Komplexität, und es müssen mehrere Probleme besondere Aufmerksamkeit erhalten, wenn sie Ausnahmen im J2EE -Projekt behandeln.
Bei der Verwendung verteilter Anwendungen begegnen wir viele überprüfte Ausnahmen. Alle RMI -Aufrufe (einschließlich EJB -Remote -Schnittstellenaufrufe) werfen java.rmi.remoteException aus; Gleichzeitig ist RemoteException eine geprüfte Ausnahme. Wenn wir Remote -Anrufe im Geschäftssystem tätigen, müssen wir alle eine große Menge Code schreiben, um diese überprüften Ausnahmen zu verarbeiten. Sobald eine Remoteexception auftritt, sind diese überprüften Ausnahmen für das System sehr schwerwiegend, und es besteht fast keine Möglichkeit, erneut zu werden. Mit anderen Worten, wenn diese schrecklichen überprüften Ausnahmen wie RemoteException erscheinen, müssen wir keine Notwendigkeit machen, aber wir müssen viel versuchen ... Catch Code, um damit umzugehen. Im Allgemeinen tätigen wir RMI -Anrufe auf der unteren Ebene. Solange es einen RMI-Aufruf gibt, müssen alle Schnittstellen der oberen Ebene eine Remoteexception erfordern, um geworfen zu werden. Denn die Art und Weise, wie wir mit RemoteException umgehen, ist, es weiterhin hochzuwerfen. Dies wird unsere Geschäftsschnittstelle zerstören. RemoteException Diese Ausnahmen auf J2EE-Systemebene beeinflussen unsere Geschäftsschnittstellen ernsthaft. Der Zweck unserer Systemschichtung ist es, die Abhängigkeit zwischen Systemen zu verringern, und die technologischen Veränderungen in jeder Schicht beeinflussen andere Schichten nicht.
// public class Usersoaimplimples userSOA {public userInfo getUserInfo (String userID) löst RemoteException aus {//… Remote -Methode Call./………}public Interface UserManager {public userInfo getUserInfo (String UserId) Remoteexception;}} In ähnlicher Weise bringt JDBC Access eine geprüfte Ausnahme von SQLEXception.
Um das tiefgreifende Eindringen von überprüften Ausnahmen auf Systemebene in das Geschäftssystem zu vermeiden, können wir die eigene Ausnahme eines Geschäftssystems für die Geschäftsmethode definieren. Für sehr ernsthafte Ausnahmen wie SQLEXception und RemoteException können wir eine neue ungeprüfte Ausnahme definieren und dann SQLEXception und RemoteException in eine ungeprüfte Ausnahme zusammenfassen und sie werfen.
Wenn diese Ausnahme auf Systemebene an den vorherigen Anrufer übergeben werden soll, können Sie eine überprüfte Geschäftsausnahme neu definieren und die Ausnahme auf Systemebene in eine Ausnahme auf Unternehmensebene versiegeln und dann.
Im Allgemeinen müssen wir eine ungeprüfte Ausnahme definieren, damit alle Methoden der Integrationsschicht -Schnittstelle diese nicht überprüfte Ausnahme ausführen.
public dataAccessExceptionends RunTimeException {...} public interface userDao {public String getPassword (String userId) löst DataAccessException aus;} öffentliche Klasse UserDaOImplimplimples UserDao {public String getPassword (String userId) löscht DataAccessException {String SQL = "Passwort aus userInfo aus. '"+userID+"' "; try {… // JDBC ruft S.ExecuteQuery (SQL);…} catch (SQLEXception ex) {neue DataAccessexception (" Datenbankabfrage fehlgeschlagen "+SQL, Ex);}}}}}}}} Definieren Sie eine geprüfte Geschäftsausnahme, damit alle Methoden der Geschäftsschicht -Schnittstelle eine geprüfte Ausnahme ausführen.
public class businessExceptendends Ausnahme {...} public interface userManager {public userInfo CopyuSerInfo (userInfo user) löst BusinessException {userInfo newUser = null; try {newUser = (userInfo) user.clone (); Unterstützt: "+userInfo.class.getName (), ex);}}} Die J2EE -Darstellungsschicht sollte eine sehr dünne Schicht sein, und ihre Hauptfunktionen sind: Seitenanforderungen erhalten, die Seitenparameter in Pojo -Objekte zusammenstellen, die entsprechenden Geschäftsmethoden aufrufen und dann die Seite weiterleiten, die entsprechenden Geschäftsdaten auf der Seite vorlegen. Die Präsentationsschicht muss auf ein Problem achten. Die Präsentationsschicht muss die Legitimität der Daten überprüfen, z.
Alle Parameter, die von J2EE an den Hintergrund der Seite übergeben wurden, sind Zeichentyp. Wenn Sie die Eingabe von numerischen oder Datumsartparametern benötigen, muss der Zeichenwert in den entsprechenden numerischen oder Datumswert konvertiert werden.
Wenn die Parameter für die Verifizierung der Darstellungsschichtcode nicht gültig sind, sollte er an die Originalseite zurückgegeben werden, sodass der Benutzer die Daten erneut eingeben und relevante Fehlerinformationen auffordern kann.
Normalerweise wird ein aus der Seite übergebener Parameter in einen numerischen Wert konvertiert. Wir können einen solchen Code sehen
ModeAnDView HandleRequest (httpServletRequest -Anforderung, httpServletResponse -Antwort) löst eine Ausnahme aus {String agestr = request.getParameter ("Alter"); int age = Integer.Parse (agestr); SimpleDateFormat Format = new SimpledateFormat ("mm/dd/yjyy"); Datum Geburtstag = Format.Parse (Geburtstagsstrum);} Der obige Code ist häufig zu sehen, aber wenn der Benutzer ein Zeichen eingibt, das nicht in einer Ganzzahl von der Seite oder einem falschen Datumswert konvertiert werden kann.
Die Integer.Parse () -Methode wird mit NumberFormatexception eine ungeprüfte Ausnahme ausgelöst. Diese Ausnahme ist jedoch definitiv keine tödliche Ausnahme. Wenn der vom Benutzer im Feld "Seiteneintrag" eingegebene Wert illegal ist, sollten wir im Allgemeinen den Benutzer auffordern, wieder einzutreten. Aber sobald eine ungeprüfte Ausnahme ausgelöst ist, gibt es keine Chance, es erneut zu versuchen. Codes wie diese verursachen eine große Menge an Ausnahmeinformationen, die auf der Seite angezeigt werden. Lassen Sie unser System sehr zerbrechlich aussehen.
In ähnlicher Weise bringt die SimpledateFormat.Parse () -Methode auch eine ungeprüfte Ausnahme der ParseException.
In diesem Fall sollten wir diese ungeprüften Ausnahmen erfassen und den Benutzer zum Wiedereintritt auffordern.
ModeAnDView -Handlersquest (httpServletRequest -Anforderung, HttpServletResponse -Antwort) löst Ausnahme aus {String agestr = request.getParameter ("Alter"); String birthdaystr = Anfrage ex){error.reject("age","is not a legal integer value");}………try{SimpleDateFormat format = new SimpleDateFormat("MM/dd/yyyy");birthDay = format.parse(birthDayStr);}catch(ParseException ex){error.reject("birthDay","is not a legal date, please enter the date in 'MM/dd/yyy' Format ");}} In der Präsentationsschicht müssen Sie herausfinden, ob die aufrufende Methode eine deaktivierte Ausnahme ausgelegt hat, unter welchen Umständen diese Ausnahmen ausgelöst werden und die korrekte Verarbeitung vornehmen.
In der Präsentationsschicht müssen im Allgemeinen keine Ausnahmen erfassen. Wenn die von der bezeichnete Geschäftsmethode ausgelöste Ausnahme dem zweiten Rückgabewert entspricht, muss in diesem Fall erfasst werden.
Das obige ist der gesamte Inhalt dieses Artikels. Ich hoffe, es wird für das Lernen aller hilfreich sein und ich hoffe, jeder wird Wulin.com mehr unterstützen.