Exceptions

This code abuses exceptions for ordinary control flow - a serious anti-pattern because:

1. It's drastically less efficient (roughly 2x slower) than standard loops
2. It obfuscates the code's purpose, making it unreadable
3. It prevents JVM optimizations that would normally occur in try-catch blocks
4. It can mask real bugs by catching and ignoring legitimate errors

The proper alternative is a standard loop:

for (Mountain m : range)
    m.climb();

Exceptions should only be used for exceptional conditions, not regular control flow.

Cardinal rule: Use checked exceptions for conditions from which the caller can reasonably be expected to recover.

Decision factors:

• Use checked exceptions when:

  • Recovery is possible
  • You want to force callers to handle the condition
  • The condition is a legitimate outcome (not a bug)
  • You can provide methods to help with recovery

• Use runtime exceptions when:

  • The condition represents a programming error
  • Recovery is impossible or unlikely
  • Forcing exception handling would be burdensome
  • The condition results from precondition violations

If it's unclear whether recovery is possible, favor unchecked exceptions.

Remember: Checked exceptions increase API complexity but enhance reliability when used appropriately.

Problems with this exception-based loop:

1. Performance degradation:

   • Significantly slower than standard loops (exceptions are expensive)
   • JVM cannot optimize code within try-catch blocks effectively

2. Readability issues:

   • Obscures the intent of iterating through a collection
   • Violates standard Java conventions
   • Makes code maintenance harder

3. Dangerous debugging problem:

   • Will catch and silently ignore ANY NoSuchElementException
   • If processing code accidentally throws NoSuchElementException for an unrelated reason, it will be misinterpreted as normal loop termination
   • Masks bugs that should cause visible failures

4. Fails to utilize the Iterator API properly:

   • Ignores the hasNext() method specifically designed to prevent this pattern

Correct approach:

for (Iterator<Foo> i = collection.iterator(); i.hasNext(); ) {
    Foo foo = i.next();
    // process foo
}

Or better:

for (Foo foo : collection) {
    // process foo
}

Runtime Exceptions:

• Primarily indicate programming errors (precondition violations)
• Represent bugs that should be fixed, not handled at runtime
• Needn't be caught or declared
• Should be used when recovery is impossible or impractical

Examples of appropriate runtime exceptions:

• NullPointerException: Passing null to method requiring non-null
• IllegalArgumentException: Passing negative value to size parameter
• IndexOutOfBoundsException: Accessing array beyond bounds
• UnsupportedOperationException: Calling unimplemented optional method
• ClassCastException: Incorrect type casting

Checked Exceptions:

• Indicate recoverable conditions
• Represent legitimate, anticipated outcomes
• Must be caught or declared
• Should be used when caller can reasonably recover

Examples of appropriate checked exceptions:

• IOException: File not found, but caller can try another location
• SQLException: Database connection lost, but can be retried
• ParseException: Invalid date format, but user can correct input
• FileNotFoundException: Missing file that user could provide
• InsufficientFundsException: Transaction that could succeed with less money

The key difference: Runtime exceptions typically indicate bugs that should be fixed in the code; checked exceptions indicate conditions that legitimate program flows need to handle.

Exception translation is when higher layers catch lower-level exceptions and throw exceptions that can be explained in terms of the higher-level abstraction.

Use it when:

• A method would otherwise propagate exceptions from lower-level abstractions
• The original exception has no apparent connection to the task performed
• To prevent API pollution with implementation details

Code pattern:

// Exception Translation
try {
    // Use lower-level abstraction to do our bidding
} catch (LowerLevelException e) {
    throw new HigherLevelException(...);
}

This prevents breaking client code if implementation changes and maintains abstraction integrity.

Exception chaining is a special form of exception translation where the lower-level exception is preserved as the "cause" of the higher-level exception.

Implementation:

// Exception Chaining
try {
    // Use lower-level abstraction to do our bidding
} catch (LowerLevelException cause) {
    throw new HigherLevelException(cause);
}

// Creating a chaining-aware exception class
class HigherLevelException extends Exception {
    HigherLevelException(Throwable cause) {
        super(cause);
    }
}

Benefits:

• Preserves lower-level exception details for debugging
• Integrates the cause's stack trace into the higher-level exception
• Allows programmatic access to the cause (via getCause())
• Provides both abstraction integrity and debugging information
• Useful when the lower-level exception might help diagnose the problem

Best practices for documenting exceptions:

1. Document all exceptions, both checked and unchecked

   • Use Javadoc @throws tags for all possible exceptions

2. Declare each checked exception individually in the throws clause

   • Never declare superclasses like Exception or Throwable
   • Don't declare unchecked exceptions in throws clause

3. Document precisely when each exception is thrown

   • Clearly specify conditions that trigger each exception

4. For interface methods, document unchecked exceptions thoroughly

   • This forms part of the interface's general contract

5. For multiple methods throwing the same exception for the same reason:

   • Document the exception in the class's documentation comment
   • Example: "All methods in this class throw NullPointerException if a null object reference is passed in any parameter"

6. Distinguish between checked and unchecked exceptions in documentation

   • The @throws tag without a throws clause provides a visual cue that an exception is unchecked

Remember: Undocumented exceptions make it difficult or impossible for others to effectively use your classes and interfaces.

The advice against ignoring exceptions applies equally to both types, but with different implications:

Checked Exceptions:

• Represent predictable exceptional conditions
• Compiler forces you to handle them
• Ignoring them means deliberately suppressing expected error conditions
• Often indicates a failure in external resources (files, network, etc.)

Unchecked Exceptions:

• Often represent programming errors
• No compiler enforcement
• Ignoring them typically hides bugs in your code
• May indicate violation of method preconditions

Both cases result in a program that continues silently despite errors, potentially failing at arbitrary future points unrelated to the error source. The difference is primarily in what type of problem you're hiding.

Empty Catch Block:

try {
    performOperation();
} catch (Exception e) {
    // Empty - silently continues
}

• Debugging implications: Failures are hidden completely
• Program continues with potential data corruption
• Errors manifest far from their source
• Extremely difficult to diagnose problems
• No failure information preserved

Propagating Exception:

// Either no try-catch or re-throwing
performOperation(); // or throw inside catch block

• Debugging implications: Program fails fast at or near error source
• Stack trace preserves complete call context
• Error information is available for diagnosis
• Prevents cascading errors from corrupt state
• Makes the failure visible and traceable

Even when you can't handle an exception properly, letting it propagate is vastly superior for debugging compared to silently ignoring it.

Patterns for Failure Atomicity in Complex Operations:

1. Command Pattern: Encapsulate operations as objects that can track changes and undo them if needed

2. Memento Pattern: Capture and externalize object state before operations to restore if needed

3. Transactional Memory: Use software or hardware transactional memory systems that automatically roll back on failure

4. Copy-on-write: Create a complete copy before modification and only switch references on success

5. Builder Pattern with final commit: Build up changes in a separate object and apply them atomically at the end

6. Two-phase commit: Prepare all changes first (can be rolled back), then commit them if all preparations succeed

7. Snapshot isolation: Work on a logical snapshot of data, only updating the main state atomically on completion

The appropriate technique depends on performance requirements, object complexity, and the nature of the operations being performed.