Is doesn't seem silly to anybody else that an error handler that relies on a DB connection is itself, yet another single point of failure?
If you've experienced a fatal error, or even a badly handled non-fatal error, I can't see this is going to help you much. Heh, if the error is because of a database issue, you're likely just going to be going in circles ;) You don't want a small failure to escalate to the point where it becomes a bigger issue ;) Better to dump to a text file - the only thing that can go wrong with that is permissions error or disk error (full/failure). Possibly automatically fire it off in an email... On 20 Mar 2009, at 13:09, saad wrote: > > Hi, > I got the exact same problem. I tried to look at the code, but without > any success. > > Did you find a solution? > > Thanks, > > Saad > > On Feb 28, 8:26 pm, Brian Racer <[email protected]> wrote: >> There is sfErrorLogger >> <http://www.symfony-project.org/plugins/sfErrorLoggerPlugin> and >> sfDoctrineErrorLogger >> <http://www.symfony-project.org/plugins/sfDoctrineErrorLoggerPlugin>. >> However when I was testing sfErrorLogger with Propel(Symfony 1.2 and >> Propel 1.3), it would break with database exceptions since it would >> try >> and serialize the exception object which contained a PDO instance >> which >> you cannot do. I posted this to the dev mailing list >> <http://groups.google.com/group/symfony-devs/browse_thread/thread/8fb3... >> >, >> but it never received any response. >> >> *Brian Racer >> * >> Lead Developer >> JetPack Web Development, LLC >> (715) 834-3349 office >> [email protected] <mailto:[email protected]> >> >> >> >> Sid Bachtiar wrote: >>>> "Exception in sfCache". So? What should I do with that info? It >>>> took >>>> me a while to figure out what the real problem was - a permissions >>>> conflict. >> >>> So, you should get stack trace rather than just short error like >>> that! >>> Your user should not see any error (which is what >>> sfErrorHandlerPlugin >>> does) but you as developer should see the stack trace. >> >>> Look at Firefox, IE, and etc ... they all have a feature that when >>> it >>> crash, it will try to send stack trace back to the developer. >> >>> Why? Because there is no way you can ever 100% test your application >>> for every possible situations, so when it crash or throw error, the >>> stack trace is very valuable information to developer. >> >>> On Sat, Feb 28, 2009 at 4:49 PM, Lawrence Krubner >>> <[email protected]> wrote: >> >>>> On Feb 27, 8:57 pm, Sid Bachtiar <[email protected]> wrote: >> >>>>> I think log4php is not really needed as symfony has built in >>>>> logging >>>>> capability. But sending error to an email address is definitely >>>>> missing from Symfony. >> >>>>> Any website owner would want to know if there's an error on their >>>>> website because it would affect their users/visitors. >> >>>> It is simple to write a cron job to sift through the error logs and >>>> send you an email when there is an error on your site. I've written >>>> such scripts before, they generally take me 15 to 30 minutes, >>>> depending on the number of if() conditions I need to add. >> >>>> Or you can simply make it a habit to look at your error logs. Big >>>> sites normally have a programmer or sysadmin who is watching that >>>> kind >>>> of stuff. >> >>>> But in the end, the result is always the same. No matter whether >>>> you >>>> use a plugin, a cron script, or if you manually look at the error >>>> logs >>>> - you still end up seeing the same error message either way. >>>> And, at >>>> least for me, the error message was almost useless. It was >>>> cryptic - >>>> "Exception in sfCache". So? What should I do with that info? It >>>> took >>>> me a while to figure out what the real problem was - a permissions >>>> conflict. >> >>>>> On Sat, Feb 28, 2009 at 2:50 PM, Lee Bolding <[email protected]> >>>>> wrote: >> >>>>>> I started thinking about that - look in SVN, and you'll see I >>>>>> started >>>>>> adding Log4PHP ;) >> >>>>>> I never got round to finishing it though. Ideally, Log4PHP >>>>>> wouldn't be >>>>>> integrated in this plugin anyway - it would be another plugin to >>>>>> dynamically replace Symfony's built in logging classes... a job >>>>>> for >>>>>> another day ;) >> >>>>>> At the moment it works as-is - I'm concerntrating on >>>>>> sfDynamicFormsPlugin at the moment :) >> >>>>>> On 28 Feb 2009, at 00:36, Sid Bachtiar wrote: >> >>>>>>> Hey, that's a nice plugin! >> >>>>>>> One very very useful feature that could be added is send stack >>>>>>> trace >>>>>>> error to an email address, e.g.: when there's error (any >>>>>>> error), send >>>>>>> email to the developer/admin. >> >>>>>>> On Sat, Feb 28, 2009 at 1:28 PM, Lee Bolding >>>>>>> <[email protected]> wrote: >> >>>>>>>> Or, install sfErrorHandlerPlugin >> >>>>>>>> http://www.symfony-project.org/plugins/sfErrorHandlerPlugin >> >>>>>>>> :) >> >>>>>>>> On 28 Feb 2009, at 00:21, Lawrence Krubner wrote: >> >>>>>>>>> What a mess. >> >>>>>>>>> I post this as a warning for others. >> >>>>>>>>> I did something that caused Symfony to crash. It might have >>>>>>>>> been a >>>>>>>>> change to a yaml file. I ended up facing a pure white >>>>>>>>> screen. No >>>>>>>>> error >>>>>>>>> messages. I was looking at the development controller. >>>>>>>>> Nothing. >> >>>>>>>>> I got an earlier version of my yaml file out of Subversion. I >>>>>>>>> cleared >>>>>>>>> the cache several times - no help. >> >>>>>>>>> I lost over a day trying to figure out the problem. >> >>>>>>>>> Finally, I realized that me, Subversion and PHP were having a >>>>>>>>> dispute >>>>>>>>> over permissions, regarding the cache. Symfony wasn't able >>>>>>>>> to clear >>>>>>>>> the cache, because Subversion had ended up with some rights >>>>>>>>> to the >>>>>>>>> folder. I chmoded the cache to 777, cleared the cache, and got >>>>>>>>> things >>>>>>>>> working again. >> >>>>>>>>> So here is the moral of this story: when facing a blank white >>>>>>>>> screen, >>>>>>>>> chmod the cache folder to 777. At least you can remove that >>>>>>>>> as a >>>>>>>>> potential problem. >> >>>>>>> -- >>>>>>> Blue Horn Ltd - System Development >>>>>>> http://bluehorn.co.nz >> >>>>> -- >>>>> Blue Horn Ltd - System Developmenthttp://bluehorn.co.nz- Hide >>>>> quoted text - >> >> - Show quoted text - > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "symfony users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/symfony-users?hl=en -~----------~----~----~----~------~----~------~--~---
