A typographical error on an operation can lead to unexpected results. For example, if the intention is to add a number to a variable using += but it is written as =+, the operation is still valid. However, instead of carrying out the addition, it re-initializes the variable.

Example 1 The following code is intended to add a number to the variable numberOne. However, using the =+ operator actually re-initializes the variable to 1.

uint numberOne = 1;

function alwaysOne() public {
    numberOne =+ 1;
}

A call made to an external contract can fail, which might cause a Denial of Service inside the calling contract if the failure is not handled correctly. Which can leave the contract unavailable for further use.

This is especially relevant when the external call is executed inside a loop statement and even more when dealing with payments, where it is usually better to let users withdraw funds instead of pushing funds to them.

Example 1: The following code uses a for loop statement to refund all involved addresses by using the send external call.

function refundAll() public {
    for(uint x; x < refundAddresses.length; x++) {
        require(refundAddresses[x].send(refunds[refundAddresses[x]]));
    }
}

Just about every serious attack on a software system begins with the violation of a programmer's assumptions. After the attack, the programmer's assumptions seem flimsy and poorly founded, but before an attack many programmers would defend their assumptions well past the end of their lunch break.

Two dubious assumptions that are easy to spot in code are "this method call can never fail" and "it doesn't matter if this call fails". When a programmer ignores a condition, they implicitly state that they are operating under one of these assumptions.

Example 1: The following code excerpt ignores an error condition that might happen during a CICS transaction.

...
EXEC CICS
  INGNORE CONDITION ERROR
END-EXEC.
...

If a transaction were to ever fail with this error condition, the program would continue to execute as though nothing unusual had occurred. The program records no evidence indicating the special situation, potentially frustrating any later attempt to explain the program's behavior.

A ColdFusion application might inadvertently display detailed error messages to the user. These error messages might contain sensitive information that can enable an attacker to conduct more targeted or damaging attacks.

Just about every serious attack on a software system begins with the violation of a programmer's assumptions. After the attack, the programmer's assumptions seem flimsy and poorly founded, but before an attack many programmers would defend their assumptions well past the end of their lunch break.

Two dubious assumptions that are easy to spot in code are "this method call can never fail" and "it doesn't matter if this call fails". When a programmer ignores an exception, they implicitly state that they are operating under one of these assumptions.

Example 1: The following code excerpt ignores a rarely-thrown exception from doExchange().

try {
  doExchange();
}
catch (RareException e) {
  // this can never happen
}

If a RareException were to ever be thrown, the program would continue to execute as though nothing unusual had occurred. The program records no evidence indicating the special situation, potentially frustrating any later attempt to explain the program's behavior.

Just about every serious attack on a software system begins with the violation of a programmer's assumptions. After the attack, the programmer's assumptions seem flimsy and poorly founded, but before an attack many programmers would defend their assumptions well past the end of their lunch break.

Two dubious assumptions that are easy to spot in code are "this function call can never fail" and "it doesn't matter if this call fails". When a programmer ignores an exception, they implicitly state that they are operating under one of these assumptions.

Example 1: The following code ignores several exceptions that could be thrown while executing the insert statement.

PROCEDURE do_it_all
IS
BEGIN
  BEGIN
    INSERT INTO table1 VALUES(...);
    COMMIT;
  EXCEPTION
    WHEN OTHERS THEN NULL;
  END;
END do_it_all;

An exception could be thrown because the table does not exist, a required value is not provided, or some other reason. If a failure occurs, there is no way to tell because the procedure will not report the failure or record what type of failure has occurred.

Multiple catch blocks can get repetitive, but "condensing" catch blocks by catching a high-level class such as Exception can obscure exceptions that deserve special treatment or that should not be caught at this point in the program. Catching an overly broad exception essentially defeats the purpose of Java's typed exceptions, and can become particularly dangerous if the program grows and begins to throw new types of exceptions. The new exception types will not receive any attention.

Example 1: The following code excerpt handles three types of exceptions in an identical fashion.

  try {
    doExchange();
  }
  catch (IOException e) {
    logger.error("doExchange failed", e);
  }
  catch (InvocationTargetException e) {
    logger.error("doExchange failed", e);
  }
  catch (SQLException e) {
    logger.error("doExchange failed", e);
  }

At first blush, it may seem preferable to deal with these exceptions in a single catch block, as follows:

  try {
    doExchange();
  }
  catch (Exception e) {
    logger.error("doExchange failed", e);
  }

However, if doExchange() is modified to throw a new type of exception that should be handled in some different kind of way, the broad catch block will prevent the compiler from pointing out the situation. Further, the new catch block will now also handle exceptions derived from RuntimeException such as ClassCastException, and NullPointerException, which is not the programmer's intent.

Declaring a method to throw Exception or Throwable makes it difficult for callers to do good error handling and error recovery. Java's exception mechanism is set up to make it easy for callers to anticipate what can go wrong and write code to handle each specific exceptional circumstance. Declaring that a method throws a generic form of exception defeats this system.

Example 1: The following method throws three types of exceptions.

public void doExchange()
  throws IOException, InvocationTargetException,
         SQLException {
  ...
}

While it might seem tidier to write

public void doExchange()
  throws Exception {
  ...
}

doing so hampers the caller's ability to understand and handle the exceptions that occur. Further, if a later revision of doExchange() introduces a new type of exception that should be treated differently than previous exceptions, there is no easy way to enforce this requirement.

Programmers typically catch NullPointerException under three circumstances:

1. The program contains a null-pointer dereference. Catching the resulting exception was easier than fixing the underlying problem.

2. The program explicitly throws a NullPointerException to signal an error condition.

3. The code is part of a test harness that supplies unexpected input to the classes under test.

Of these three circumstances, only the last is acceptable.

Example 1: The following code mistakenly catches a NullPointerException.

  try {
    mysteryMethod();
  }
  catch (NullPointerException npe) {
  }

Programmers typically catch NullReferenceException under three circumstances:

1. The program contains a null-pointer dereference. Catching the resulting exception was easier than fixing the underlying problem.

2. The program explicitly throws a NullReferenceException to signal an error condition.

3. The code is part of a test harness that supplies unexpected input to the classes under test.

Of these three circumstances, only the last is acceptable.

Example 1: The following code mistakenly catches a NullReferenceException.

  try {
    MysteryMethod();
  }
  catch (NullReferenceException npe) {
  }

A return statement inside a finally block will cause any exception that might be thrown in the try block to be discarded.

Example 1: In the following code excerpt, the MagicException thrown by the second call to doMagic with true passed to it will never be delivered to the caller. The return statement inside the finally block will cause the exception to be discarded.

public class MagicTrick {

public static class MagicException extends Exception { }

public static void main(String[] args) {

  System.out.println("Watch as this magical code makes an " +
                     "exception disappear before your very eyes!");

  System.out.println("First, the kind of exception handling " +
                     "you're used to:");
  try {
    doMagic(false);
  } catch (MagicException e) {
    // An exception will be caught here
    e.printStackTrace();
  }

  System.out.println("Now, the magic:");
  try {
    doMagic(true);
  } catch (MagicException e) {
    // No exception caught here, the finally block ate it
    e.printStackTrace();
  }
  System.out.println("tada!");
}

public static void doMagic(boolean returnFromFinally)
throws MagicException {

  try {
    throw new MagicException();
  }
  finally {
    if (returnFromFinally) {
      return;
    }
  }
}

}

ThreadDeath errors should only be caught if an applications needs to clean up after being terminated asynchronously. If a ThreadDeath error is caught, it is important that it be re-thrown so that the thread actually dies. The purpose of throwing ThreadDeath is to stop a thread. If ThreadDeath is swallowed, it can prevent a thread from stopping and result in unexpected behavior since whoever originally threw ThreadDeath expects the thread to stop.

Example 1: The following code catches ThreadDeath but does not re-throw it.

try
{
//some code
}
catch(ThreadDeath td)
{
//clean up code
}

In Java, finally blocks are always executed after their corresponding try-catch blocks and are often used to free allocated resources, such as file handles or database cursors. Throwing an exception in a finally block can bypass critical cleanup code since normal program execution will be disrupted.

Example 1: In the following code, the call to stmt.close() is bypassed when the FileNotFoundException is thrown.

public void processTransaction(Connection conn) throws FileNotFoundException
{
    FileInputStream fis = null;
    Statement stmt = null;
    try
    {
        stmt = conn.createStatement();
        fis = new FileInputStream("badFile.txt");
        ...
    }
    catch (FileNotFoundException fe)
    {
        log("File not found.");
    }
    catch (SQLException se)
    {
        //handle error
    }
    finally
    {
        if (fis == null)
        {
            throw new FileNotFoundException();
        }

        if (stmt != null)
        {
            try
            {
                stmt.close();
            }
            catch (SQLException e)
            {
                log(e);
            }
        }
    }
}

Unhandled exception vulnerabilities occur when:

1. An exception is thrown

2. The exception is not properly handled before it escapes the current page.

Just about every serious attack on a software system begins with the violation of a programmer's assumptions. After the attack, the programmer's assumptions seem flimsy and poorly founded, but before an attack many programmers would defend their assumptions well past the end of their lunch break.

Two dubious assumptions that are easy to spot in code are "this operation can never fail" and "it doesn't matter if this operation fails". When a programmer fails to catch an exception that an operation may throw, they implicitly state that they are operating under one of these assumptions.

Unhandled SSL exception vulnerabilities occur when:

1. An SSL-specific exception is thrown.

2. The exception is not explicitly handled.

The SSL-specific exceptions javax.net.ssl.SSLHandshakeException, javax.net.ssl.SSLKeyException, and javax.net.ssl.SSLPeerUnverifiedException all convey important errors related to an SSL connection. If these errors are not explicitly handled, the connection can be left in an unexpected and potential insecure state.

Just about every serious attack on a software system begins with the violation of a programmer's assumptions. After the attack, the programmer's assumptions seem flimsy and poorly founded, but before an attack many programmers would defend their assumptions well past the end of their lunch break.

Two dubious assumptions that are easy to spot in code are "this operation can never fail" and "it doesn't matter if this operation fails". When a programmer fails to catch an exception that an operation may throw, they implicitly state that they are operating under one of these assumptions.