I currently handle errors during AJAX requests in a manner similar to this:
try {
// code
if (some_error_condition) {
throw new \Exception('error');
}
// other code
if (some_other_error_condition) {
throw new \Exception('other error');
}
// more code
$response = array(
'success' => TRUE,
'data' => 'stuff here'
);
} catch (Exception $e) {
$response = array(
'success' => FALSE,
'error' => $e->getMessage()
);
}
header('Content-Type: application/json');
echo json_encode($response);
My question is: is there a better way to handle multiple possible error conditions than this, while still adhering to DRY principles? I think this method is much cleaner and easier to follow than giant nested if/else messes, but it's a little reminiscent of goto code.
Perhaps an OOP way?
it is completely valid solution for me, except you could use different exception classes for your exception and encapsulate actual logic in some object, like
class Handler {
//this function executes code and throws exception - no error handling logic.
public static function doSomeCode() {
(...)
return $response;
}
}
try {
$response = Handler::doSomeCode();
renderResponse();
} catch (SomeError $e) {
$err = 'some error';
renderError($err);
} catch (Exception $e) {
header('500 Internal Server Error'); //this is pseudo code!
}
your exception classes (except generic Exception) could handle rendering errors, Exception class would trigger 500 (it should never happend). This way you separate actual code execution from error handling, and with proper exceptions object model dont repeat yourself with error handling.
Related
I have some IF/THEN logic that is getting difficult to read, and am thinking of using using exceptions instead.
The code will test the user input, and throw exceptions as appropriate. My catch statement will deal with the anticipated exceptions, but if the exception is not anticipated (like I messed up a PDO statement), I wish to throw the exception and let PHP's error system deal with it. All of the anticipated exceptions are pretty much dealt with the same way, and I don't wish to use multiple try/catches around each test.
Within the catch statement, how can I perform different actions based on the exception?
try {
$user_input=$_POST['user_input'];
// rest of code here...
if (test1($user_input)) {
throw new Exception("Anticipated exception 1.");
}
// rest of code here...
//Some PDO which might generate a non-anticipated exception
if (test2($user_input)) {
throw new Exception("Anticipated exception 2.");
}
// rest of code here...
}
catch (Exception $e) {
if(anticipatedException($e)) {
//Deal with it
}
else {
throw $e;
}
}
By using different exceptions. i.e.
class ExceptionOne extends Exception {}
class ExceptionTwo extends Exception {}
try {
$user_input=$_POST['user_input'];
// rest of code here...
if (test1($user_input)) {
throw new ExceptionOne("Anticipated exception 1.");
}
// rest of code here...
//Some PDO which might generate a non-anticipated exception
if (test2($user_input)) {
throw new ExceptionTwo("Anticipated exception 2.");
}
// rest of code here...
}
catch (ExceptionOne $e) {
/*...*/
}
catch (ExceptionTwo $e) {
/*...*/
}
Also check Predefined exceptions which might help to group yours: http://php.net/manual/en/spl.exceptions.php
I want to know which is the way to implement error in RestAPI, actually if a method in my classes generate an exception I return this ...
if(mysqli_connect_errno()) {
throw new Exception("Can't connect to db.");
}
... but this is a bad practice 'cause an API should be return a json.
So my idea is create a class called Errors and, in each class, when an error is fired I simply call the relative error number for display the json error.
Someone have another idea?
Maybe something like so :
<?php
try {
// Do your stuff
if(mysqli_connect_errno()) {
throw new Exception("Can't connect to db.");
}
} catch (Exception $e) {
echo json_encode(array("success" => false, "message" => $e->getMessage()));
return;
}
I think #Gwendal answer is good but it's no enough just to return a json response, you also have to return the proper http code:
<?php
try {
// Do your stuff
} catch (Exception $e) {
header($_SERVER['SERVER_PROTOCOL'] . ' 500 Internal Server Error', true, 500);
echo json_encode(array("success" => false, "message" => $e->getMessage()));
return;
}
I think you're in the right path. There are a couple of concerns that you're dealing with in here. First one is error handling, whilst the second one is error formatting.
Error handling can be done in several ways, and throwing exceptions is one of them. In order to find out when something bad happened, you'll need to wrap your exceptions within a try/catch block:
try {
//logic
if(mysqli_connect_errno()) {
throw new Exception("Can't connect to db.");
}
//more logic
} catch (Exception $e) {
//handle the error here
}
If you're following this route, I'd suggest you to be more specific in your exceptions, so you can better build your responses in your API. It's not the same having the DB down than to not being able to find a resource, for instance:
try {
//logic
if(mysqli_connect_errno()) {
throw new DBException("Can't connect to db.");
}
if(is_null($entity)) {
throw new ResourceNotFoundException("Entity could not be found");
}
//more logic
} catch (DBException $e) {
//handle DB error here
} catch (ResourceNotFoundException $e) {
//handle resource not found error here
}
Now for the formatting part, the normal response in REST APIs are JSON responses. One way to go about it, would be to create a specific class whose sole responsibility would be to transforms your response into a valid JSON:
...
} catch (DBException $e) {
return $this->JSONResponse->format("Sorry we could not complete your request", 500);
} catch (ResourceNotFoundException $e) {
return $this->JSONResponse->format("The resource you were looking for could not be found", 404);
}
As you can see, different errors have different status codes. The implementation of the class is quite trivial:
class JSONResponse {
public function format($message, $statusCode) {
return json_encode(['message' => $message, 'code' => $statusCode]);
}
}
This does not change the status code of the response though, which is essential to good REST API design. You'll need to set the appropriate status code by using this function.
You can find a more robust and flexible implementation of this class in the Symfony HTTPFoundation Component, which extends from the normal Response class.
My RESTful API always returns a JSON of this structure:
[
'resource' : [],
'code' : [
'id' : int,
'msg' : string
],
'meta' : [],
'log' : []
]
If I return data, the data is always in resource and code['id'] is always 0 (which represents 'OK'). When an error occours, I return an empty resource and some error code. Also I provide some extra information via meta and can log some actions via log which helps me a lot with debugging.
This might also help you with future issues, for example if you want to split an answer into pages so the client should request data via GET /path/to/resource/page/:page or want to notice the client that a certain request path is deprecated.
My question is about the correct usage of Php Exceptions.
My Php app is an API server.
My code base is quite articulated, to a depth of 5-6 levels of nested calls.
Of course exceptions are a very handy way to handle an error,
since you don't have to handle all error conditions on every level of your function calls...
To better explain what I mean, I make an exaple below.
This is a simplified excerpt from my top level code (the "router"):
...
$this->app->get("/persons/get", function() {
try {
$persons = new PersonsController($this);
$this->success($persons->get());
} catch (Exception $e) {
$this->error($e);
});
};
...
private function error($error) {
$response = $this->app->response();
$response->body(json_encode([
"error" => [
"message" => $error->getMessage(),
]));
}
And this is a simplified excerpt from my bottom level code (the "db"):
...
public function get($table) {
try {
$sql = "SELECT * FROM '$table'";
$statement = $this->db->prepare($sql);
$statement->execute();
$result = $statement->fetchAll(PDO::FETCH_ASSOC);
return $result;
} catch (PDOException $e) {
throw new Exception("Error getting persons: ", 0, $e);
}
}
I think this is a typical and effective example of useful exception handling: on a fatal error in the bottom level of the code base, the error automatically pops up to the main error handling function. The real advantage here is I don't have to mess up with handling the error condition all along the chain of functions code, from the router level through the db level...
But, what if I should use Exceptions more extensively, in the middle of my functions stack... For example:
class PersonsController {
...
public function sync() {
if (!mkdir($d, 0777)) {
throw new Exception("Can't create folder $d");
}
}
...
}
Instead of, for example:
class PersonsController {
...
public function sync() {
if (!mkdir($d, 0777)) {dir: DEBUG ONLY!
return -1; # this error code will have to be handled upper in the stack...
}
}
...
}
The question is: How extensive can be the use of Exceptions in a Php non-trivial project?
I have a problem where I want to catch all exception except descendants of my custom exception.
Maybe bad design, but here it is (Simplified and names changed, but the code is quite accurate):
function doStuff()
{
try {
// code
if (something) {
// manually throw an exception
throw StuffError("Something is bad.");
}
// a third-party code, can throw exceptions
LibraryClass::arcaneMagic();
} catch (Exception $e) {
throw new StuffError("Error occured while doing stuff: "
. $e->getMessage());
}
}
/** My custom exception */
class StuffError extends Exception
{
function __construct($msg) {
parent::__construct('StuffError: ' . $msg);
}
}
However, the issue here is that I don't want the try-catch to intercept the manually throws StuffError. Or, seamlessly rethrow it or something.
As it is now, I'd get:
StuffError: Error occured while doing stuff: StuffError: Something is bad.
I want just:
StuffError: Something is bad.
How would I do it?
You can have multiple catch clauses, and the first one that matches will be the one that runs. So you could have something like this:
try {
do_some_stuff();
}
catch (StuffError $e) {
throw $e;
}
catch (Exception $e) {
throw new StuffError(Error occurred while doing stuff: " . $e->getMessage());
}
But you might want to rethink wrapping stuff like this. It obscures the real cause of the error. For one thing, you lose the stack trace. But it also complicates error handling, since now someone can't differentiate exception types the way you're trying to do, short of trying to parse the exception message (which is rather an anti-pattern in itself).
I might be misinterpreting you, but I think this is what you're looking for:
...
} catch (Exception $e) {
if (get_class($e) == 'StuffError' || is_subclass_of($e, 'StuffError')) {
throw $e;
} else {
throw new StuffError("Error occured while doing stuff: "
. $e->getMessage());
}
}
...
Replace your catch statement with the code above. It checks to see if the exception is a StuffError or a child class of StuffError. I'm still very confused at why you would need to throw a StuffError exception after you catch, but maybe that's just some weirdness coming from translating/cleaning your code.
I have a custom exception class that extends Exception and adds on the ability to pass back more data on what threw the exception. The problem now is if I want to catch my custom exception and a standard exception, but handle them with the same block of code, I don't know how to do that other than create a new function (which I don't want to do for every place I'd like to use this).
try {
} catch(QM\DebugInfoException $e) {
// I don't want to duplicate the Exception handling code up here
}catch(Exception $e){
$db->rollBack();
$return['error'] = 1;
$return['errInfo'] = array(
'code' => $e->getCode(),
'message' => $e->getMessage(),
'trace' => $e->getTraceAsString()
);
// I'd rather handle both here, and just add data on to $return['errInfo']
switch ($ExceptionType) {
case 'QM\DebugInfoException':
$return['errInfo']['extraInfo'] = $e->getExtraInfo();
break;
}
}
Does anyone have any good ideas on this?
You could do a get_class($e) and that will return the string representing the class name of the exception object then use that to compare in your switch.
Another option is to put a function that encapsulates the common functionality, and call it from each of the exception blocks. That way new, unexpected exceptions not in your switch can still percolate up. I'm a big fan of explicitly catching specific exceptions.