1
Download objects
Transcript
09: Handling Exceptions - 245 EInvalidOp EZeroDivide EOverflow EUnderflow EAccessViolation EPrivilege EControlC EQuit EInvalidCast EConvertError ECodesetConversion EVariantError EPropReadOnly EPropWriteOnly EAssertionFailed EAbstractError EIntfCastError EInvalidContainer EInvalidInsert EPackageError ECFError EOSError ESafecallException EMonitor EMonitorLockException ENoMonitorSupportException EProgrammerNotFound ENotImplemented EObjectDisposed EJNIException note I don't know about you, but I still have to figure out the exact usage scenario of what I consider the most odd exception class, the EProgrammerNotFound exception. Now that you have seen the core exceptions hierarchy, I can add one piece of information to the previous description of the except-on statements. These statements are evaluated in sequence until the system finds an exception class matching the type of the exception object that was raised. Now the matching rule used is the type compatibility rule we examined in the last chapter: an exception object is compatible with any of the base types of its own specific type (like a TDog object was compatible with the TAnimal class). This means you can have multiple exception handler types that match the exception. If you want to be able to handle the more granular exceptions (the lower classes of the hierarchy) along with the more generic one in case none of the previous matches, you have to list the handler blocks from the more specific to the more generic (or from the child exception class up to its parent classes). Also, if you write a handler for the type Exception it will be a catch-all clause. Here is a code snippet with two handlers in one block: Marco Cantù, Object Pascal Handbook
