I have started to play with the dev version of ZF2 in the current dev-develop branch and since then I am getting white screen on every exception, thrown somewhere in the views.
I have installed the SkeletonApplication to see, if it is something in my application, that was causing it, but same problem appear there too. Downgrading to dev-master solves the problem and I am getting the standard exception dump.
Looking into the zf2 code I think I have found the reason for this. In Zend\Mvc\View\Http\DefaultRenderingStrategy::render() now we have:
public function render(MvcEvent $e)
{
......
try {
$view->render($viewModel);
} catch(\Exception $ex) {
$application = $e->getApplication();
$events = $application->getEventManager();
$e->setError(Application::ERROR_EXCEPTION)
->setParam('exception', $ex);
$events->trigger(MvcEvent::EVENT_RENDER_ERROR, $e);
}
return $response;
}
So the Exception is catched, but the response is empty and I have no clue about the cause of the latter.
However another question appears: How is the error handler going to render the exception page, if the error is triggered in the layout? (Like in my case - the navigation helper, which was unable to find the container.) The only possible solution is to have an extra error layout, but this is pointless, since the reason of having a nice exception handling is not present anymore.
So following questions are arising:
How do ZF2 developers plan to solve the issue?
Is there a current workaround (actually commenting out the try { } catch() { } fixes the problem, but is not a good solution)
Since the pull request, which brought the above code, is closed, am I doing anything entirely wrong and am I completely wrong about the way it should work?
Check your zf2 config files to make sure you have opened exception display options:
'view_manager' => array(
'display_not_found_reason' => true,
'display_exceptions' => true,
),
Related
I'm developing my own PHP framework and my code althought is working like it should, it's getting bigger and bigger; that of course leads to multiple ways for my framework to break, so I have decided it is time to implement Exception handling like any other PHP framework does, that 'nice' error view that tells you what might went wrong.
I have done my research and kind of understand how the Extension PHP default class works, I know that I'm able to extend this class and customize the error messages.
I also know that to trigger an Exception you gotta throw it and catch it with a "try/catch" statement, somethin like this...
class MyCustomException extends \Exception()
{
// My stuff
}
public function dontBeZero($number)
{
if ($number == 0) {
throw new MyCustomException('You gave me zero!!');
}
}
try {
dontBeZero(0);
} catch (MyCustomException $e) {
echo '<pre>';
$e->getMessage();
echo '</pre>';
}
I understand that, but my real question is: How does this popular frameworks such as Laravel, Symfony, etc manage to throw you a pretty message showing you what the error was, where do they keep all the logic that verifies whether it should or should not throw an exception, and most importantly where did they catch them?.
Most frameworks show these errors via a custom error handler. A popular one used by laravel is whoops.
You just need to register it as a custom handler, and you'll see the pretty error pages:
$whoops = new \Whoops\Run;
$whoops->pushHandler(new \Whoops\Handler\PrettyPageHandler);
$whoops->register();
Keep in mind, you should disable these on production (so that your stack traces/code isn't exposed).
See the two functions set_error_handler and set_exception_handler. These functions allow you to register a callback function which is called when an error or exception occurs.
These callback functions are called by the Php runtime and provided with error details as arguments. The error details include error line number, stack trace, file name and more. The callback function can then format and display this information
This question already has answers here:
Disable Laravel's built-in error handling methods
(7 answers)
Closed 1 year ago.
In Laravel, whenever there error, even minor NOTICES, WARNINGS and DEPRECATED erros, I got the full debug info which kills the application. In my App.config I've turned debug => false and I get the message of 'Whoops, looks like something went wrong.'
How can I turn off all error handling but Laravel to just get normal PHP errors that do not interrupt the entire flow of application?
If you don't want to interrupt your workflow for certain PHP error types, you will need to disable the error handler registered by Laravel for those errors.
Laravel registers its error handling in Illuminate/Foundation/Bootstrap/HandleExceptions.php. This bootstrapper is one of several that is called when your Http kernel handles a request.
While there are a couple ways to do what you want to do, I think the easiest is to handle the event that is fired after this bootstrapper is called. In the event handler, you can reset the error handler for the errors you don't want Laravel to process.
In your bootstrap/app.php file, add the following line right before $app is returned:
$app->afterBootstrapping(
'Illuminate\Foundation\Bootstrap\HandleExceptions',
function ($app) {
set_error_handler(function ($level, $message, $file = '', $line = 0, $context = []) {
// Check if this error level is handled by error reporting
if (error_reporting() & $level) {
// Return false for any error levels that should
// be handled by the built in PHP error handler.
if ($level & (E_WARNING | E_NOTICE | E_DEPRECATED)) {
return false;
}
// Throw an exception to be handled by Laravel for all other errors.
throw new ErrorException($message, 0, $level, $file, $line);
}
});
}
);
The App\Exceptions\Handler.php file is built just for this.
In the public function render() method, you can catch applications and perform certain redirects/page views if you so choose:
For instance, you can capture HttpException's in your application and then return an error page if you wished:
public function render($request, Exception $e)
{
//other stuff
if ($e instanceof HttpException) {
return view('errors.general')->withErrors([
'message' => 'The application encountered an error!'
]);
}
return parent::render($request, $exception);
}
That up-voted answer is the opposite of what he asked.
As far as I can tell, there isn't a way to separate error reporting and laravel taking over rendering of the screen. I've been looking through the Laravel 5 code and haven't found a way to split them apart using their setup yet.
You could write your own library to totally take over all error handling and remove all of laravels internal tracking, but then you'd have to make sure to pass it back to laravel in the cases where you need the orig page error handling. Easiest way would be find a 3rd part error handler vendor then modify it to take over all error handlers and not block rendering.
This is a general question regarding exception handing for exceptions thrown in onther people's code.
I am using the following Codeigniter PHP library: https://github.com/sepehr/ci-mongodb-base-model
which relies upon this library for MongoDB: https://github.com/alexbilbie/codeigniter-mongodb-library/tree/v2
If I call a function in the first library, and it then calls one from the second. Sometimes the second library throws exceptions which I want to be able to deal with in my own code, but there is a try-catch statement around the exception throwing call, which means that it is dealt with before I get a chance to (I just prints the exception to the screen).
My question is:
Without modifying all of the functions in the first and second libraries (i.e. removing all of the try catches), how can I deal with the exception that is thrown?
EDIT
This is how the functions in the second library are arranged:
class SomeClass
{
function do_something()
{
...
try {
...
}
catch {
$this->_show_error('Update of data into MongoDB failed: ' . $exception->getMessage(), 500);
}
}
function _show_error($error_message = '', $response_code = 500)
{
//Inbuilt Codeigniter helper function which can be disabled from printing the error to the screen
show_error($error_message, $response_code);
}
}
Although I can disable the error from being printed (which is of course just for debugging), I still have no way of knowing that it occurred and handling it.
(should be a comment rather than an answer, but it's a bit long)
just prints the exception to the screen
Really? Are you sure?
Did you check it doesn't trigger an error instead of an exception and you're running this on a system which is not configured as a production server?
If so then I'd steer way clear of this as a library.
(I sincerely doubt anyone would write code that dumb and publish it without lots of warnings)
I have below code in error.php, which is triggered using App::abort(404, $error) in my controller. Still my response status code is 200(ok). I tried with various error codes like 400, 403
// NotFoundException handler
App::error(function(NotFoundException $e)
{
$default_message = 'The requested resource was not found';
return Response::json(array(
'error' => $e->getMessage() ?: $default_message,
), 404);
});
For anyone still googling this problem:
I was struggling with this problem for hours. For me the problem was caused by an issue with one of my controllers.
Check all of your controllers and make sure there are no spaces in front of the <?php tag. The <?php tag should be the very first thing in the file. A single space in front of the <?php tag in any of your controllers that are routed as such:
Route::controller('example', 'ExampleController');
Will cause all status codes to be 200.
I believe, regardless, you should receive a 404 response, so there might be something else happening that's the result of code not included in your question.
That being said, the Exception class that is thrown for 404 is NotFoundHttpException rather than NotFoundException.
Since Laravel 4 uses Symfony's HttpKernal, that Exception is here.
You can see here where App::abort() throws NotFoundHttpException when a 404 is triggered.
Therefore, your code should look like:
// NotFoundHttpException handler
App::error(function(\Symfony\Component\HttpKernel\Exception\NotFoundHttpException $e)
{
$default_message = 'The requested resource was not found';
return Response::json(array(
'error' => $e->getMessage() ?: $default_message,
), 404);
});
Important: This will only fire for a 404 status, as that's the corresponding code to NotFoundHttpException. Other status codes return other Exception classes. To capture all HTTP status error codes exceptions, type hint for HttpException like so:
// HttpException handler
App::error(function(\Symfony\Component\HttpKernel\Exception\HttpException $e)
{
return Response::json(array(
'error' => $e->getMessage(),
), $e-> getStatusCode());
});
Lastly, consider using a bit of Content Negotiation when deciding to return JSON or HTML.
The solution didn't worked for me, so in case anyone is still looking for an answer, I thought it be best to put it here instead of creating another question.
After some time I had this problem too, in my app/Exceptions/Handler.php I had:
if ($e instanceof ModelNotFoundException) {
if ($request->ajax()) {
return response()
->json(['error' => ['No results']])
->header('status', 422);
}
}
This worked in my local environment, however, in the homolog environment (which reproduces the production environment, just to be clear) it didn't returned the correct status code.
After another look I started looking at Laravel's docs, and I changed the call to the following:
return response()
->json(['error' => ['No results.']], 422);
And that did the trick. Hope this can help.
In my case I found some space in front of <?php
Remove dump & other print functions
I was actively debugging when I noticed this issue. It was caused because I had dump(...) calls in the code at that time.
When I removed all my debug dump calls, the status code was correctly 404 again (using abort(404).
I'm trying to develop a personal MVC framework for learning purposes. But every time I'm stuck in this problem: errors.
I feel like I'm handling them very bad. Currently I have an exception system (everything is converted to exception, even PHP triggered errors) that is catch in a try{} block that contains every line of code of the framework and the user application.
I'm treating errors such as "controller not found" or "action not found" like any other, for example "unable to connect to the database". But I feel like the latter is somehow more an "exception" rather than a pretty common "controller not found (404)".
Also currently I'm using an error handling that pretty much copy the way MVC works in my framework, in the sense that when an error occurs I load a specific action and load a specific view file for each type of error. I'm not using the MVC (by MVC I mean all the mechanism that load a controller, run an action, load a model and views for the user application) of my framework because an error in the MVC could cause an error to be triggered, which would try to manage it with the MVC which would trigger the same error again and then the MVC to be loaded again and so on in an infinite loop.
How should I handle every error of my framework? What are the best practice right now?
The execution of controller IMHO can generate two exceptions:
not found: when controller or method is missing
permission denied: when ACL blocked access
To handle this, i would just go with something like following code. And you can use multiple catch block.
try
{
$controller->$command($request, $response);
}
catch(AccessDeniedException $e)
{
$controller = new ErrorController;
$controller->accessDenied($request, $response);
}
catch(NotFoundException $e)
{
$controller = new ErrorController;
$controller->notFound($request, $response);
}
You can let AccessDeniedException to bubble up from Model Layer too, but usually it is a bad practice. Exception should be handles within same level of abstraction, where it was thrown, or, in case of critical exceptions (when object itself is unable to deal with it), the exceptions might penetrate ONE abstraction boundary. And exceptions should NOT leave the Model Layer, instead they should create error state in the layer, and be processed in your current View instance.
The point is this: instead of magical handler for all errors, you should handle errors close to the place where it originated.
You can do something like a more proper message at the try catch. For example:
try
{
//Your code here
}
catch (Exception $e)
{
// Clean the output buffer if one exists
ob_get_level() and ob_clean();
// Display the exception text
echo sprintf('%s [ %s ]: %s ~ %s [ %d ]', get_class($e), $e->getCode(), strip_tags($e->getMessage()), $e->getFile(), $e->getLine())."\n";
// Exit with an error status
exit(1);
}