| Poor man's exception chaining. Used to both convert exceptions to
RuntimeExceptions and to throw real exceptions. The print routines
are careful to only print the inner (ie most complete) stack trace.
SimpleORM takes care to trap most error conditions and throw
meaningful exception messages. Unlike most other Java code, they
always include information about which objects were being processed at
the time, eg. the primary key of the current record. We strongly
encourage this practice as it greatly facilitates maintenance and
debugging.
Subclasses are actually thrown, namely
SException.Error to indicate probable bugs in the user's
program, SException.InternalError to indicate bugs in
SimpleOrm, SException.JDBC for chained JDBC errors,
SException.Data for errors that probably the result of
run-time data problems. SException.Test is used to
indicate failed test cases.
Other well defined exceptions that a user may want to trap are given
explicit subclasses
(eg. SRecordInstance.BrokenOptimisticLockException).
SimpleORM only throws SExceptions which extend RuntimeException and so
avoid the need to clutter the code with unnecessary try/catch blocks.
The only reason to use try/catch when using SimpleORM is because you
really want to catch an error.
(The author stongly disagrees with the way that Java forces one to
declare and catch exceptions because it encourages mediocre
programmers to hide exceptions which is a very nasty practice. (Even Sun
programmers do this quite regularly in the Java libraries,
eg. System.out.println()!) It also clutters
the code for no good reason. IMHO Java's "checked" exceptions
add no value whatsoever in practice.)
| 