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_conf
ig_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
-~----------~----~----~----~------~----~------~--~---
