Skip to content


Subversion checkout URL

You can clone with
Download ZIP


Add sane handling of errors that happen before the frapi error handler has been initialised #183

merged 1 commit into from

3 participants


No description provided.


Good idea actually. I approve :)


It looks like Frapi_Error does make it before the controller has been initialised, updated the commit to handle that case.

@davidcoallier davidcoallier merged commit ec4b884 into frapi:master

Why the ob_* friends instead of var_export with debug_backtrace?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Commits on Jul 10, 2012
  1. @kudos
This page is out of date. Refresh to see the latest.
Showing with 8 additions and 7 deletions.
  1. +8 −7 src/frapi/library/Frapi/Controller/Api.php
15 src/frapi/library/Frapi/Controller/Api.php
@@ -208,14 +208,15 @@ public static function processInternalError(Frapi_Exception $e)
+ } catch(Frapi_Error $e) {
+ // If it's just a Frapi_Error, we want to rethrow it.
+ throw $e;
} catch (Exception $e) {
- // This is a hack to intercept anything that may
- // have happened before the internal error collection
- // during the initialisation process.
- //
- // If we got here, we have no controller and cannot properly handle
- // output, so we just send a 500 and die.
+ // We have no controller or error handler,
+ // so send some indication somewhere that things went wrong.
+ ob_start();
+ debug_print_backtrace();
+ error_log(ob_get_clean());
header("HTTP/1.0 500 Internal Server Error");
Something went wrong with that request. Please try again.