In BioJava, checked exceptions are generally preferred to RuntimeExceptions, but RuntimeExceptions can be used as a fall-back if you are implementing an interface which doesn't support checked exceptions. If you do this, please document this clearly in the implementing class.
Occasionaly methods will document that the object they return may emit BioRuntimeExceptions. If you know what you are doing, you can catch these and do something sensible with them. An example would be an iterator() method that returns an Iterator where next() could fail due to a database connection flaking out. This could raise a BioRuntimeException wrapping the real cause. It would then not be unreasonable for the code calling next() to catch this BioRuntimeException and extract the cause. Occasionaly it is necisary to abuse the exception system by throwing BioError to get arround limitations in APIs that you do not control. For example, when implementing Iterator.next(), you may need to call a method that can fail. Catch the failure and throw it as a BioError. If you want people to handle this gracefully in their scripts, then document this behavior and hope they catch the error. @author Matthew Pocock @author Thomas Down @since 1.0 | |