Cool - np - and I'm sure you'll do the same for me someday ;) Applied the line and it fixes the problem.
-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Lee Bolding Sent: 01 May 2009 18:09 To: [email protected] Subject: [symfony-users] Re: Best practice for debugging ? Well, sfErrorHandler *IS* working - sfLegacyErrorException is a standard PHP error that sfErrorHandlerPlugin has caught with its error_handler and rethrown as an sfLegacyException (which allows you to control error handling slightly easier). You are correct though, that should be suppressed because of the @ operator. I've just had a quick look on the PHP website, seems I was meant to implement a handling of the @ operator in my error_handler like so... // if error has been supressed with an @ if (error_reporting() == 0) { return; } I'll make the fix over the weekend and update SVN and the PEAR package. In the meantime, you can add those lines after this line... public static function error_handler($code, $message, $file, $line, $context = null) { in lib/sfErrorHandler.class.php Sorry about that - I wasn't aware it was up to the error handler to deal with @ operator On 1 May 2009, at 16:49, David Ashwood wrote: > Although I'm now seeing an exception when using the browser that I > don't think should be shown. > > 500 | Internal Server Error | sfLegacyErrorException > unlink(D:\development\sfForum\cache\frontend\dev\config/ > modules_default_config_view.yml.php) [<a > href='function.unlink'>function.unlink</a>]: No such file or directory > stack trace > > * at () > in SF_ROOT_DIR\lib\vendor\symfony\lib\config > \sfConfigCache.class.php line 352 ... > 349. @fclose($fp); > 350. > 351. chmod($tmpFile, 0666); > 352. @unlink($cache); > 353. rename($tmpFile, $cache); > 354. umask($current_umask); > 355. } > > Line 352 should fail silently. > > -----Original Message----- > From: [email protected] [mailto:[email protected] > ] On Behalf Of Lee Bolding > Sent: 01 May 2009 17:38 > To: [email protected] > Subject: [symfony-users] Re: Best practice for debugging ? > > > TBH, I've never tested it like that. > > sfErrorHandlerPlugin needs the filter chain to work, I haven't yet > investigated whether the sfCommandApplication stuff uses the filter > chain or not. > > Suck it and see - let me know :) > > On 1 May 2009, at 16:22, David Ashwood wrote: > > > > > Talking about sfErrorHandlerPlugin - does it handle symfony cli > > exceptions? > > I have a weird problem at the moment and I'm wondering it will help. > > > > I'm converting an old plugin from using Propel to DBFinder/Doctrine. > > Now the changes are only half done the schema appears to be > converted > > properly and some of the fixtures are working - but when it attempts > > to load > > a subset of the fixtures I get a hard crash. Hard as in the PHP cli > > crashes > > out. There's nothing in the phperror log and I don't see any errors > > reported - making it difficult to track down. Now I suspect that > > it's just > > because I've not finished converting the models but it's annoying as > > I like > > to stepwise the changes. > > > > > > > > -----Original Message----- > > From: [email protected] [mailto:[email protected] > > ] > > On Behalf Of Lee Bolding > > Sent: 01 May 2009 16:45 > > To: [email protected] > > Subject: [symfony-users] Re: Best practice for debugging ? > > > > > > I'd expect a debugger to stop at an exception that wasn't handled - > > that's a fatal error. > > > > Shameless self promotion (again) - sfErrorHandlerPlugin wraps the > > entire filter chain (except for itself) inside of a try/catch block, > > so it automatically catches any uncaught exceptions and displays the > > full stack trace :) > > > > If you're using any kind of 3rd party library, it's a handy way to > > insulate your application from bad exception handling in a 3rd party > > library. > > > > > > On 1 May 2009, at 14:52, David Ashwood wrote: > > > >> > >> It varies but generally it was catching all exceptions even if > >> they're not > >> handled. > >> I've worked with various php debuggers over the years - so it's > >> something I > >> test when using a new version or changing the debugging lib used. > >> > >> -----Original Message----- > >> From: [email protected] > > [mailto:[email protected] > >> ] > >> On Behalf Of Lee Bolding > >> Sent: 01 May 2009 15:29 > >> To: [email protected] > >> Subject: [symfony-users] Re: Best practice for debugging ? > >> > >> > >> > >> On 1 May 2009, at 13:07, David Ashwood wrote: > >> > >>> Generally though I've had problems getting PHP debuggers to ignore > >>> certain files (such as code within frameworks when an exception > >>> happens). > >> > >> Is this uncaught exceptions? or do you mean they tend to stop > >> whenever > >> an exception is thrown, even if it is caught and dealt with? > >> > >> > >> > >>> > > > > > > > > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
