CI_Exceptions::show_error wrong behaviour

[KN4CK3R]

I found a strange behaviour with the show_error method.
Test code looks like this:

Controller:

$this->load->view('exists');

View (exists.php):

This should not be visible
<?php
$this->load->view('does_not_exists');
?>

The call to $this->load->view('does_not_exists'); triggers an error because the view does not exist.
The generated output looks like this: http://abload.de/img/testzrswq.jpg
I would expect only the error message to be displayed, like if the controller would use $this->load->view('does not exists');.

I found this because my view looked like this:

<div style="display:none">
<?php
$this->load->view('does_not_exists');
?>
</div>

which suppresses the error message.

[narfbg]

Just to clarify - I do consider this to be a bug, but I wouldn't at all be surprised if somebody actually depends on the current behavior, so I'm thinking of fixing it in version 3.1 (pending some internal discussion).

[aanbar]

If it's going to block the entire response when failing to load a view, then I think this should have a backtrace to show which view is requesting the non-existent view.
At its current form, when the error is being displayed in certain block, You know which view contains the wrong load->view.

[narfbg]

Well, that's if this is only relevant to views loading other views, but that's unclear right now.

[jim-parry]

I do not agree that this is a bug.
With the original view shown (nothing about CSS styling), the text before the PHP tag is sent to the browser as expected.
When the error message is triggered, that is trapped by CI and added to the browser output.

If there were a PHP error, I would expect to see the PHP error message(s), and then the contents of the view, including any CI error messages.

[narfbg]

It is contentious, indeed.

If we consider an error displayed after e.g. a hundred lines of output, it could be hard to spot or even completely hidden via styling. On the other hand, not discarding previous output helps in (visually) spotting where the error has occurred.

[narfbg]

#4189 (and #4220 in particular) makes this one obsolete.