Thanks to visit codestin.com
Credit goes to github.com

Skip to content

[WebProfiler] Can't consult the exception panel when there is an exception #8441

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from

Conversation

Taluu
Copy link
Contributor

@Taluu Taluu commented Jul 8, 2013

Q A
Bug fix? yes
New feature? no
BC breaks? no (not yet)
Deprecations? no
Tests pass? yes
Fixed tickets not reported yet AFAIK
License MIT
Doc PR none

When consulting the Exception Panel of the Web Profiler, there was an exception stating that the ResponseHeaderBag expects an array as a typehint, and it has a string instead

An exception has been thrown during the rendering of a template ("Catchable Fatal Error: Argument 1 passed to Symfony\Component\HttpFoundation\ResponseHeaderBag::__construct() must be of the type array, string given

This was induced in the commit 6d2135b.

The thing is, as I already discussed on IRC with @lsmith77, I think it is strange that the Response's constructor does not have a typehint on the $headers parameter, as it is directly fed to the ResponseHeaderBag, on the very first instruction of the mentionned controller, which provokes the mentionned error. So either we can add the typehint on the Response, or we can also typehint the parameter :

<?php

class Response
{
    // ...
    public function __construct($content = '', $status = 200, $headers = array())
    {
        $this->headers = new ResponseHeaderBag((array) $headers);
    }

    // ...
}

Though I think it is not as neat as the typehint directly on the parameter, but I heard that it was a no-go to add a typehint on object's constructor, as this could be a potential BC Break. Is it still the case ? Even though this call are here for at least 2 years now...

Cheers.

@Taluu
Copy link
Contributor Author

Taluu commented Jul 8, 2013

Hum, I don't know if I shold maybe post this PR on the 2.2 branch instead of master ? Feedback is welcome here. if it is the case, i'll close this one and reopen it on the 2.2 branch.

@Taluu
Copy link
Contributor Author

Taluu commented Jul 8, 2013

Hum it seems it was already resolved in 6dbd1e1, but not tagged yet or merged into master. I'm leaving the PR open regarding the discussion on the Response typehint.

@fabpot
Copy link
Member

fabpot commented Jul 8, 2013

The response type hint cannot be changed for BC reasons.

@fabpot fabpot closed this Jul 8, 2013
@Taluu
Copy link
Contributor Author

Taluu commented Jul 8, 2013

Yes, but as far as i can read, it seems that this would not really be a BC Break, it would report the error on the typehint only on an earlier level ?

The error on the wrong type (string instead of expected array) is present for a pretty long time (over 2 years I think) ? So it would not really be a BC Break : the guy using this object would still have a PHP Error, but on an earlier level than what is currently in place.

@Tobion
Copy link
Contributor

Tobion commented Jul 8, 2013

For reference this was already fixed and the typehint discussed in #8350.
@fabpot Again, it does not affect BC.

@Taluu Taluu deleted the fix-exception-panel branch September 9, 2015 09:53
@Taluu Taluu restored the fix-exception-panel branch September 9, 2015 09:53
@Taluu Taluu deleted the fix-exception-panel branch September 9, 2015 09:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants