Re: exceptions

Alan Knowles wrote:

Wow - nothing like a light read after a hard day removing rootkits :) I'm not sure how this could be handled with PEAR_ErrorStack, but DataObjects and Flexy have both evolved a user configurable critical error handling mechanism, which theoretically may suit this cunundarum.. * Beginners are going to be totally baffled/annoyed by exceptions. * Exception purists are going to be fustrated if PEAR doesnt embrace them. both Flexy & DataObjects use an internal raiseError, with lazy loading of PEAR Error.. eg. ... somewhere in code: return DB_DataObject::raiseError(

    "some message %s",
    DB_DATAOBJECT_ERROR_SOMEID,
    DB_DATAOBJECT_ERROR_DIE,
     .....

); function raiseError($msg,$id,$howbad) {

    $c = $GLOBALS['_DB_DATAOBJECT']['config']
    $hbad = isset($c['error_map'][$howbad]) ?
        $c['error_map'][$howbad] : $howbad;
    require_once 'PEAR.php';
    $r = PEAR::raiseError(.......... 'DB_DataObject_Error');
    if ($hb == DB_DATAOBJECT_ERROR_EXCEPTION) {
        eval('raise $r;');
    }
    return $r;

} While not perfect code, it does illustrate the nature that best practice may be to default returning / dieing, if you want / need exceptions, the library should be capable of 'growing' to suit others needs.. Regards alan

This is exactly the kind of thing that I was thinking. You set PEAR_ERROR_RETURN or PEAR_ERROR_EXCEPTION. If the coder selectes exceptions, they get them *instead of* PEAR_Errors. Either should work. -- paperCrane <Justin Patrin>