Worauf kommt es bei einem OurCompanyRuntimeException-Typ in Java an?

Question

In dem Unternehmen, in dem ich gerade bin, gibt es viele Stellen im Code, an denen eine OurCompanyRuntimeException ausgelöst wird (wobei OurCompany der eigentliche Name des Unternehmens ist). Soweit ich das beurteilen kann, wird diese Ausnahme als "Eine Laufzeitausnahme durch Code, den wir hier bei dieser Firma geschrieben haben, beschrieben."

Ich bin etwas Neues zu Java, aber ich dachte Ausnahmetypen sollten reflektieren, was schief gelaufen ist, nicht , dessen Code die Ausnahme ausgelöst hat. Beispiel: IllegalArgumentException bedeutet, dass jemand ein ungültiges Argument an etwas weitergegeben hat. Sie hätten keine SunIllegalArgumentException, wenn ein ungültiges Argument in von Sun geschriebenem Code und dann eine IBMIllegalArgumentException übergeben würde - das wäre albern und sinnlos, oder? Und wenn Sie wissen möchten, wo die Ausnahme ausgelöst wurde, sehen Sie sich die Stack-Trace an. Ich verstehe, dass ich RuntimeException erweitern möchte (damit Sie nicht mehr so ​​viele Versuche/Fänge oder "Würfe" haben), aber warum nicht Unterklassen erstellen, die erklären, was passiert ist, im Gegensatz zu dem Code des Unternehmens in dem es passiert ist?

Hat schon einmal jemand die OurCompanyRuntimeException-Idee verwendet oder hat er eine Vorstellung davon, warum sie es so gemacht haben?

Answer 1

Klingt wie der übliche Code-Unsinn, den du in den internen Code-Basen für mich findest. Ich vermute, wenn du fragst, dass es ein Dekret gegeben hat, dass die OurCompanyRuntimeException basierend auf einer fehlgeleiteten Logik von einem Senior-Typ verwendet wurde, den niemand in Frage stellte und schon lange weiter ging - die Geschichte der monkeys, bananas and hose-pipes springt in den Sinn.

Ich stimme Ihnen zu, der Name der Ausnahme sollte einen Hinweis auf den Fehler geben, der aufgetreten ist.

Answer 2

Hilft beim Lesen von Stack-Spuren, das ist sicher. I.e. Wenn Sie durch viele Zeilen von "verursacht durch" scannen, hilft es zu sehen, dass es in etwas auftrat, das von Ihnen geworfen wurde, nicht in etwas, das beispielsweise einem Container innewohnt.

Sie können auch benutzerdefinierte Aktionen als Teil des Throwable ausführen - z. Schreibe in ein spezielles Log irgendwo, usw.

Answer 3

Dies ist ein schlechtes Konzept. Ausnahmen sollten spezifisch für einen Anwendungsfall sein.

Okay, wenn das Unternehmen eine Menge von fehlerhaftem Code/Produkten produziert, können sie diese Art von Ausnahme als Werbung verwenden;)

Answer 4

Ja ich gestoßen, dass auch, aber es keinen Sinn für mich gemacht hat entweder. Meine Vermutung war, dass die Firmen diese Ausnahmen sehr früh nach der Einführung von Java geschrieben haben, ohne die richtige Vorstellung davon zu bekommen, wie Exception-Throwing und Handling wirklich funktionieren (wie Nick bereits sagte ... vom Senior-Programmierer wagte niemand zu hinterfragen). Wenn das Unternehmen die Notwendigkeit hat, eine eigene Ausnahmeklasse zu erstellen (z. B. für firmenspezifische Protokollports), sollte diese Ausnahme niemals direkt ausgelöst werden (abstrakt). Ich würde stattdessen ein konkretes Problem ableiten, das Ausnahmen beschreibt, oder einfach der Spring Framework-Idee für Exception handling/throw folgen.

Answer 5

Ihr Unternehmen fügt möglicherweise Code zu einem bereits vorhandenen Projekt hinzu, z. B. eine Open-Source-Code-Basis, und könnte nur sehr wenig Code hinzugefügt haben. Um also Fehler zu erkennen, die von den Entwicklern des Unternehmens verursacht wurden, dachten sie, dass sie ihre eigene Ausnahmeklasse haben würden, um die Fehler, die vorher da waren, von denen zu unterscheiden, die durch die Erweiterung verursacht wurden. Auf diese Weise können sie sich nur auf diejenigen konzentrieren, die von den Entwicklern des Unternehmens verursacht werden, und vielleicht die ursprünglichen Quellcode-Betreuer bitten, die anderen zu reparieren.

Mit der Zeit, wenn Sie eine ausreichend große Codebasis durch interne Entwicklung entwickelt haben, können Sie weitere Ausnahmen hinzufügen und entfernen Sie die FirmennameRuntimeException altogother. Außerdem können sie sich besser mit dem Know-how der Entwickler vertraut machen, damit sie alle Fehler wie einen behandeln können und nicht diejenigen, die von Unternehmensentwicklern verdächtiger verursacht werden.

Answer 6

Es wäre sehr sinnvoll, dies als Basisklasse für bestimmte Ausnahmen zu haben. Sie haben eine bestimmte Ausnahme ausgelöst und die Basisklasse abgefangen.

Auch kann es erlauben, eine Ursache (die REAL-Ausnahme) plus zusätzliche Informationen herum zu tragen. Dies kann sehr nützlich sein, um eine Diagnoseausgabe für die Protokollierung zu erstellen.

Answer 7

Scheint ziemlich dumm, Logging-Ausgabe oder ein Stack-Trace zeigt Ihnen, wer die schuldige Klasse ist, so dass die Erklärung nicht waschen. Es scheint auch gefährlich zu sein, als ob Leute dazu ermutigt werden, die OurCompanyRuntimeException zu werfen, die RuntimeExceptions auslöst, die den Anrufer nicht dazu zwingen, sie zu handhaben und die Anwendung herunterfahren können.

Ich stimme Ihnen zu, dass Ausnahmen den Grund widerspiegeln sollten. Ich habe eine benutzerdefinierte Ausnahme als Stamm einer Hierarchie gesehen, obwohl sie wahrscheinlich abstrakt sein sollte, so dass Sie eine bestimmte Erweiterung erstellen müssen, um eine zu verwenden, und es sollte definitiv keine RuntimeException sein.

Answer 8

Es wäre keine schlechte Idee, eine generische unternehmensweite Ausnahmeklasse zu haben, wie Sie beschreiben, von der spezifischere Ausnahmefälle erben. In einer Antwort wurde bereits erwähnt, dass die Fähigkeit, interne Code-Exceptions zu erkennen und die Core-Java-Code oder den Code von Drittanbietern zu ignorieren/zu ignorieren. Der Schlüsselpunkt hier ist, dass spezifischere Ausnahmen von diesem erben sollten. Eine generische Ausnahme mit dem Namen "Company" zu nennen, wäre selten erforderlich und wird fast nie empfohlen.