Exceptions: Bloch 2nd Edition

1
Exceptions Bloch 2nd Edition

• Items 57-65
• Last modified Fall 2008
• Paul Ammann

2
Item 57 Use Exceptions only for Exceptional
Conditions

• Dont do this!
• try int i0
• while (true)
• rangei.climb()
• catch(IndexOutOfBoundsException e)
• Note that code may hide unrelated exception!
• Implications for API design
• Provide state testing method instead of forcing
  client to catch exception.

3
More Item 57

• Do this instead
• for (Mountain m range) m.climb()
• Note
• (implicit) State Testing method
• I lt range.length
• No possibility of unintentionally hiding
  IndexOutOfBoundsException from climb()
• Bottom line Dont use exceptions for ordinary
  flow control

4
More Item 57

• How about
• try
• Iterator i collection.iterator()
• while (true)
• Foo foo (Foo) i.next()
• catch(NoSuchElementException e)
• versus
• for (Iterator i collection.iterator()
  i.hasNext())
• Foo foo (Foo) i.next() ...

5
More Item 57

• Two basic options
• State testing method
• Doesnt work in concurrent environment
• State may change between state test and actual
  call
• May be undesirable if state testing method is as
  much computation as actual call
• Then, its better to have a distinguished return
  value
• Distinguished return value
• May not be an unused special value
• Example null for Object return types
• Iterator next() method can legitimately return
  null
• Faulty use of distinguished return value model
  harder to detect

6
Item 58 Checked vs. Unchecked

• Unchecked exceptions indicate programming errors
• Precondition violations
• Recovery is impossible
• Checked exceptions indicate recoverable
  conditions
• Force the caller to handle the exception

7
More Item 58

• Use unchecked exceptions if
• client has nothing to do
• OutOfMemoryException
• client knows better
• doesnt need try-catch block if-then block would
  suffice.
• Use checked exceptions if client has some
  reasonable action
• IOException ? Calling code is correct, but
  exception can still be raised!

8
Item 59 Avoid Unnecessary Use of Checked
Exceptions

• try obj.action(args)
• catch(SomeCheckedException e)
• throw new Error (Assertion Error)
• // should never happen
• What is the point of making a client do this?
• Conditions for using checked exceptions
• Exceptional condition cannot be prevented by
  proper use of the API
• Programmer can take some useful action

9
More Item 59

• Standard Transformation
• if (obj.actionPermitted(args))
• obj.action(args)
• else
• // Handle exceptional condition
• Or even simply (where appropriate)
• obj.action(args) // Client allows call to
  fail

10
Item 60 Favor Use of Standard Exceptions

• IllegalArgumentException
• - Inappropriate parameter several special cases
• NullPointerException (param null where
  prohibited)
• IndexOutOfBoundsException (index param out of
  range)
• ClassCastException

11
More Item 60

• IllegalStateException
• Object state is inappropriate for method
  invocation
• Object may not be initialized before calling
  accessing its state
• Special subtype ConcurrentModificationException
• Concurrent modification detected where not
  allowed
• UnsupportedOperationException
• Object does not support the method
• Substitution principal

12
More Item 60

• Reasons to use standard exceptions
• Using your API is easier
• Reading your programs is easier
• Performance advantage (relatively minor)
• No additional namespace to manage

13
Item 61 Throw Exceptions Appropriate to the
Abstraction

• Propagated exceptions may make no sense
• Higher layers should translate lower level
  exceptions
• try
• catch(LowerLevelException e)
• throw new HigherLevelException()
• // Bad example
• public int min (int a)
• int minVal a0 // Bad!! Throws
  IndexOutOfBoundsException
• for (int val a) if (val lt minVal) minVal
  val
• return minVal

14
More Item 61

• Exception Chaining Transformation
• try
• // Use low level abstraction to satisfy
  contract
• catch (LowerLevelException cause)
• throw new HigherLevelException (cause)
• Achieves 2 very different goals
• Gives client exception at expected level of
  abstraction
• Also preserves low level detail for failure
  analysis

15
Item 62 Document All Exceptions Thrown by Each
Method

• Checked Exceptions
• Declare (required by compiler)
• And Document (with _at_throws tag in JavaDoc)
• Unchecked Exceptions
• Document (with _at_throws tag in JavaDoc)
• Dont shortcut with superclass exceptions
• Example Dont catch Exception instead of
  NullPointerException
• Ok to document common exceptions at class level
• Example All methods in class throw
  NullPointerException if a null object reference
  is passed in any parameter

16
Item 63 Include Failure-Capture Information in
Detail Messages

• Uncaught exceptions result in printing of stack
  trace, including detail messages
• These messages should contain values of all
  parameters that contributed to the exception
• In other words, include relevant state
  information
• Example IndexOutOfBoundsException includes upper
  bound, lower bound, and offending index

17
Item 64 Strive for Failure Atomicity

• Failure atomicity
• A failed method invocation should leave the
  object in the state that it was in prior to the
  invocation
• Ways to achieve this effect
• Design immutable objects
• Check parameters for validity before performing
  the operation
• Order the computation parts that fail come
  before modification
• Write recovery code cause the object to roll
  back its state
• Perform the operation on a temporary copy of the
  object

18
More Item 64

• public int addMax(ListltIntegergt list, Integer x)
  throws
• //pre true
• //post if x is not max wrt list, throw IAE
• // else append x to list
• Dont throw exception in between modifications to
  state variables
• Procedure should have an atomic effect
• throw exception in the beginning if you are not
  sure you can pull it off

19
More Item 64

• public Object pop() throws
• //Requires this ! EmptyStack
• //Modifies this
• //Effects pops this and returns top
• Object result elements--size
• elementssize null
• return result
• // Note Client can corrupt state oops!

20
More Item 64

• public Object pop() throws
• //Requires
• //Modifies this
• //Effects If this empty throw ISE
• // else pop this and returns top
• if (size 0) throw new ISE()
• Object result elements--size
• elementssize null
• return result
• // Note atomic execution, normal or exception

21
Item 65 Dont Ignore Exceptions

• Programmers should never leave a catch block
  empty
• Its easy to ignore exceptions, but dont!
• try
• catch(Exception e)
• // empty catch block wont raise complaints from
  compiler! Dont do this!

22
More Item 65

• If its empty, its highly suspect
• The purpose of exception is to force programmers
  handle exceptional conditions
• At least have a comment which explains why its ok
  to ignore this exception