Exceptions und Prozessbeendigung
Verwende keine Exceptions statt if...else-Statements (GCG18001) 
Exceptions sollten nicht verwendet werden, um Entscheidungen zu treffen, sondern um Fehler entsprechend ihrer Ursache und möglichen Auswirkungen zu behandeln.
Diese Regel kombiniert u. A. die Regeln GCG18002 und CGC18003.
Werf keine Exceptions die direkt wieder gefangen werden (GCG18002) 
// not okay!
class Foo {
public void AnyMethod() {
try {
throw new Exceptions();
} catch {
// do something
}
}
}
// also not okay
class Foo {
public void AnyMethod() {
try {
MethodThrowingException();
} catch {
// do something
}
}
private void MethodThrowingException() {
throw new Exception();
}
}
// maybe okay
class Foo {
public void AnyMethod() {
try {
MethodThrowingException();
} catch {
// do something
}
}
public void MethodThrowingException() {
throw new Exception();
}
}
// okay!
class Foo {
public void AnyMethod() {
try {
new Bar().MethodThrowingException();
} catch {
// do something
}
}
}
class Bar {
public void MethodThrowingException() {
throw new Exception();
}
}
Statt NullPointer-Exceptions zu fangen, prüfe sie vorzeitig ab (GCG18003)
NullPointer-Exceptions entstehen, wenn ein Objekt einen nicht erwarteten Zustand hat. Statt im Prozess solche Exceptions abzufangen, sollten sie früh erkannt und entsprechend behandelt werden.
Werf eine Exception, statt eine Art von Status-Code zurückzugeben (GCG18004)
Eine Codebasis die Rückgabewerte verwendet um einen Status (erfolgreich oder
fehlgeschlagen) zu kommunizieren, tendiert dazu, viele verschachtelte
if-Statements überall verteilt zu haben. Oft wird auch vergessen, den
Rückgabewert ordentlich zu prüfen.
Geworfene Exceptions können abgefangen oder durch eine genauere Exception
ersetzt werden, um sie an auf einer höheren Ebene zu behandeln. In den meisten
Systemen ist es normal, dass Exceptions immer dann geworfen werden, wenn eine
unerwartete Situation auftaucht.
Werf eine möglichst genaue Exception (GCG18005)
Wenn es möglich ist, eine Exception von einem spezifischen Typ zu werfen, dann sollte ein Typ gewählt werden, der bereits ohne zusätzliche Message genau aussagt, was passiert ist.
Nutze aussagekräftige Exception-Messages (GCG18006)
Die Exceptions-Message sollte den Grund für die Exception erklären und eindeutig beschreiben was getan werden muss, um die Exception zu vermeiden.
Vermeide das Verbergen von Fehlern durch das Abfangen von generischen Exceptions (GCG18007)
Vermeide das Abfangen von nicht spezifischen Exceptions, wie z. B. Exception,
SystemException etc. Nur auf der höchsten Ebene, als letzte Chance eine
Exception abzufangen, sollten nicht spezifische Exceptions behandelt werden,
um einen graceful Shutdown zu ermöglichen.
Richtige Verwendung und Dokumentation von Exit-Codes (GCG18008)
Es sollte immer sichergestellt werden, dass beim Beenden der Applikation ein zutreffender Exit-Code ausgegeben wird. Dadurch ist es anderen Systemen möglich auf das Beenden der Anwendung zu reagieren, außerdem können Benutzer nachvollziehen wie und warum eine Anwendung beendet wurde.
Es hat sich etabliert, dass der Exit-Code 0 für ein erwartetes und
erfolgreiches Beenden steht, hingegen alle abweichenden einen Fehler oder
eine unerwartete Situation repräsentieren.
Alle Exit Codes müssen dokumentiert werden!
Logging bei gezwungener Beendigung (GCG18009)
Wenn die Anwendung unerwartet beendet wird, sollte der Grund mit dem höchsten Log-Level dokumentiert werden.