Re: Exceptions was Basic DB/MDB Question
| From: | Lukas Smith | Date: | Wed, 23 Mar 2005 08:02:11 +0000 |
| Subject: | Re: Exceptions was Basic DB/MDB Question | ||
| References: | 1 2 3 4 5 6 7 8 9 10 11 12 | Groups: | php.pear.general |
| Request: | Send a blank email to pear-general+get-18263@lists.php.net to get a copy of this message | ||
Dan Rossi wrote:
Exception .. also take a look at the RFC: http://pear.php.net/pepr/pepr-proposal-show.php?id=132Dan, I suggest you check the pear-dev archives for the *extensive* discussion on Exceptions there. I was a big proponent of sticking with returns for a while but I was won over. There's also an RFC which many of us helped to write.Ok obviously I havent seen it because I am not on that list, have you got a subject i can search on ?
Actually its not like you can only use one of the error handling methods. However its not easily possible to change your code over from one to the other without considerable effort.You can code for error returns or for exceptions, but you can't just up and switch from one to the other.Hmm right ok, how could I be using try/catch on PEAR libraries that use the pear errors then ? I dont think its worth the trouble, only for my own classes and code then.
No bubbling up is something different that cant be emulated really. Bubbling up means that exceptions look withing the current scope for a catch block and if they dont they move up the stack until they find a matching catch block and then continue on from there.The paradigms are fundamentally different. As an example, think of Exceptions bubbling up vs. errors returned.Bubbling up as in error stacking which is what ErrorStack is trying to do ?
Using ErrorStack you can say that you want any error thrown to be turned into an exception. BTW you can also define a global exception handler that is called when no matching catch block is found and the entire stack has been unraveled so you can give the user a pretty error message. The point however is that switching from return errors to exceptions makes no sense within a given application. Personally I prefer return errors because they give me the freedom I want. They do mean I have tons of PEAR::isError() calls in my finished code where exception people will start to have to adding try/catch blocks from the very beginning (albeit much less of them than I need in my finished code). However the myth that alot of pro-exception people keep kicking around is that only with exceptions you dont overlook errors is simply bogus. This is exactly what setErrorHandler() is for. regards, LukasIf you code for returns but instead get bubbling up youre code is going ot behave unpredictably. The same is true for the opposite. If you code for returns and switch to exceptions you're going to end up with a lot of stupid try / catch / throw blocks which essentially do nothing. Exceptions should go straight to the code which will deal with them. errorStack doesn't "use exceptions". It has some options for exceptions, but I wouldn't say it "uses exceptions". It uses whatever error type you tell it to use (Exceptions, PEAR_Errors, arrays, etc).I dont think u read me right, I know that, if I chose to use an exception class for the ErrorStack or just standard, it still doesnt tell me how I could set error classes or Exceptions for different packages, I guess the package name in the ErrrorStack contructor is what I am suppose to do ie MDB2 etc ... So I have to setup a few ErrorStack calls ?