Regarding the [fleXive] library design, software design decisions should be applied in a consistent manner. On these pages, resources debating some of those design considerations are collected and developer viewpoints are expressed.

• Checked versus unchecked exceptions
  Checked exceptions makes the programmer aware of possible error events, but lead to mutating method interfaces when the implementation changes. Checked (runtime) exceptions allow the programmer to choose if exceptions should be handled at all, lead to cleaner interfaces, but require more care and may have side effects (e.g. EJB container rollback).
  Some articles concerning this topic:
  • Bruce Eckel (1) (2) (3): advocates the use of unchecked exceptions
  • Best Practices (onjava.com): recommends checked exceptions for error conditions that the client (program) can act upon, and unchecked for those that represent "true errors" that cannot be treated sensibly anyway (except being logged or transmitted to the user, for example).
  • Exceptions in Java: general overview (a bit dated, from 1998)
  • Exceptional Java: general guidelines, suggests to wrap checked exceptions (e.g. FxException) and use runtime exceptions for "long-term propagation of catastrophic events".
  • Exception-Handling Antipatterns: an interesting read.