Exceptions and Process Termination
Don't use exceptions instead of if...else statements (GCG18001) 
Exceptions shouldn't be used to make decisions, but to handle errors depending on their reason and impact.
This rule combines among others the rules GCG18002 and GCG18003.
Don't throw exceptions and catch them at the same time (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();
}
}
Instead of catching null pointer exceptions, introduce null validations (GCG18003)
Null pointer exceptions arise when an object has an unexpected state. Instead of catching this kind of exceptions, you should validate the objects state.
Throw exceptions rather than returning some kind of status value (GCG18004)
A code base that uses return values to report success or failure tends to have
nested if-statements sprinkled all over the code. Quite often, a caller forgets
to check the return value anyway.
Structured exception has been introduced to allow you to throw exceptions and
catch or replace them at a higher layer. In most systems it is quire common to
throw exceptions whenever an unexpected situations occurs.
Throw the most specific exception that is appropriate (GCG18005)
If it's possible to throw exceptions of a specific type, then you should that the most specific one, which don't need a message, to understand what happen.
Provide a rich and meaningful exception message text (GCG18006)
The message should explain the cause of the exception, and clearly describe what needs to be done to avoid the exception.
Don't swallow errors by catching generic exceptions (GCG18007)
Avoid swallowing errors by catching non-specific exceptions, such as
Exception, SystemException, and so on, in application code. Only in
top-level code, such as a last chance exception handler, you should catch a
non-specific exception for logging purposes and a graceful shutdown of the
application.
Right usage and documentation of exit codes (GCG18008)
The application should always send a proper exit code, when the application was shutting down. So other applications can handle the termination of the process and users can understand why and how an application was stopped.
Exit code 0 means that the application was successfully stopped without any
error. All other codes representing an unexpected situation.
All exit code must be documented!
Logging in case of unexpected shutdown (GCG18009)
If the application stops unexpected, the reason should be logged in the highest possible log level.