I'm going to sleep now, but I'm really interested in hearing comments,
both positive and negative, about the suggested mechanism.
almost only positive, that´s similar to what I´m doing now with an error class, but sometimes do not let that try() fail, eg. if error is not important enough to let the whole queue of processes fail, thus it should only be logged (or whatever), for later evalulation or not
I found this kind of continuing after throw()ing useful (it would act like what zeev does not want, it would contine after throw()ing in NOTICE-cases just with the next command and only continue below catch() if it´s a critical one an error)
well what I want to say :) I´d like to VOTE for what zeev tries to keep out (which allows implementing weird logic), because you´ll want to act differently on the error you encounter
define('USER_CUSTOM_NOTICE',1);
define('USER_CUSTOM_ERROR',2);
try() {
foobar($d) OR throw(USER_CUSTOM_NOTICE,$d); // won´t exit here
foobar($e) OR throw(USER_CUSTOM_NOTICE,$e); // " "
foobar($f) OR throw(USER_CUSTOM_ERROR,$f); // will exit here
// the above foobar is critical and try() should only fail
// if above fails
foobar($g) OR throw(USER_CUSTOM_NOTICE,$g);
}
catch($exception_data) { // catches only NOTICE
switch ($exception_type) {
case USER_CUSTOM_NOTICE:
log($exception_data); // log only
continue; // means continue try() where stopped originally
case USER_CUSTOM_ERROR:
echo($exception_data);
break; } // echo and do not return
} }
hmm looks a bit now like BASIC goto and return... :)
but to be able to continue after throw()ing has been quite useful sometimes....
andré