Class SException

All Implemented Interfaces:
Serializable
Direct Known Subclasses:
SException.Data, SException.Error, SException.InternalError, SException.Jdbc, SException.Test, SException.Validation, SRecordInstance.BrokenOptimisticLockException

public abstract class SException extends RuntimeException
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.)

See Also: