<table role="table">
<thead>
<tr>
<th>Q</th>
<th>A</th>
</tr>
</thead>
<tbody>
<tr>
<td>Bug report?</td>
<td>no</td>
</tr>
<tr>
<td>Feature request?</td>
<td>yes</td>
</tr>
<tr>
<td>BC Break report?</td>
<td>no</td>
</tr>
<tr>
<td>RFC?</td>
<td>yes</td>
</tr>
<tr>
<td>Symfony version</td>
<td>3.4 (?)</td>
</tr>
</tbody>
</table>
<p dir="auto"><em>I'm sorry if this was discussed before, but I couldn't find anything with search.</em></p>
<p dir="auto">Today I have accidentally deployed a controller with <code class="notranslate">dump()</code> in it to an environment that finally had <code class="notranslate">debug</code> flag set to <code class="notranslate">false</code> only to see a 500 error page (it was used in an action called asynchronously so I couldn't see that there are some variables dumped in the toolbar before). While I agree it's my fault for not catching this before, I also think that penalty doesn't fit the crime. To make situation like mine a little bit better I'd like to propose registering all "development" utilities (<code class="notranslate">dump()</code> et al) to be available in prod-like environments, but instead of any heavy lifting, make them do nothing. I don't have any numbers to back this up, but I believe that registering a NOP functions/twig methods will not affect overall Symfony performance. Also any overlooked calls (or even ones left on purpose) should not compromise applications' loading time. Also for those who want to fine-tune Symfony, it could be possible to not register dev utils (so get back to current situation) with a config flag.</p>
<p dir="auto">What do you think?</p>
<table role="table">
<thead>
<tr>
<th>Q</th>
<th>A</th>
</tr>
</thead>
<tbody>
<tr>
<td>Bug report?</td>
<td>no</td>
</tr>
<tr>
<td>Feature request?</td>
<td>yes</td>
</tr>
<tr>
<td>BC Break report?</td>
<td>no</td>
</tr>
<tr>
<td>RFC?</td>
<td>no</td>
</tr>
<tr>
<td>Symfony version</td>
<td>3.2</td>
</tr>
</tbody>
</table>
<p dir="auto">I'm very addicted to dump() to debug my code and i find it a invaluable tool, so thank you very much!<br>
Unfortunately some time i forget to rid off of a dump or two in the code and if the code bump into production i got an exception because dump() does not exists.</p>
<p dir="auto">I understand this should not happen and i should get more controls in place, but it happens; so my proposal: why not create a fake dump() function for production environment that does absolutely nothing?</p>
<p dir="auto">Regards,<br>
Matteo</p>