I am new to PHP exception handling and SOAP. For some reason I cannot catch a SoapFault. I don't know why. The soap server is not mine.
try {
$contact_id = $objSoapClient->getContactIdFromVisitorId('12345');
}
catch (SoapFault $sf) {
echo "Soapfault";
}
catch (Exception $e) {
echo "Exception";
}
I am purposely passing in the bad id 12345. When I enable errors I see the following message SoapFault exception: [SOAP-ENV:Client] Invalid Visitor ID. However, my catch SoapFault block nor my catch Exception block ever get hit. Why?
The code you've submitted appears to be correct. Here's the only thing that comes to my mind.
With that said, if the code is located inside a class that define a namespace, you code will not work as it will try to reference Exception as \namespace\Exception which does not exist. "Passive" references such as those in catch clauses or instanceof expressions are permitted because the missing class could be loaded later.
For it to work, you have to prefix the class name with a slash (i.e. \Exception) to tell PHP to use PHP from the global space (or root if you want to call it that) (PHP) as opposed to your namespace;
<?php
namespace test;
class Foo
{
public function bar()
{
try
{
something_that_might_break();
}
catch (\Exception $e)
{
// this will work
}
}
}
?>
You can find lots of information about namespaces here: http://php.net/manual/en/language.namespaces.php.
The problem turned out to be my SoapClient declaration. There is an exceptions parameter that must be set in order for the exceptions to trigger.
$objSoapClient = new SoapClient('https://mywebservice.com/foo.wsdl', array(
"trace" => false,
"exceptions" => true, // <-------------- This!!!
'login' => 'username', //username
'password' => 'password', //password
'features' => SOAP_SINGLE_ELEMENT_ARRAYS + SOAP_USE_XSI_ARRAY_TYPE
));
Related
I'm trying to do a very basic exception try catch, but it doesn't catch.
$id =0;
try {
$question = $this->model->find($id); // will not find anything since $id = 0
$question->delete(); // throw an exception
return true;
} catch (\Exception $e) {
dd ('hello'); // should end up here, but no?!?!?
} catch (FatalThrowableError $f) {
echo ("fatal"); // or here... but no.
}
but the catch doesn't "catch". I get an Fatal error in the browser saying that delete was called on a null object. But that's exactly what I was trying to do: do a delete on a null object (id = 0 is not in the DB), to test the exception.
I have tried
use Symfony\Component\Debug\Exception;
use Symfony\Component\Debug\Exception\FatalThrowableError;
or simply
Exception;
FatalThrowableError;
Also, having the \Exception $e or Exception $e (with or without ) doesn't change anything.
Note that if I add a line like $foo = 4/0 I get into the Exception section (dd (hello)).
in .env APP_DEBUG=true, APP_LOG_LEVEL=debug
I'm on Laravel 5.5 using PHP 7.0.10 on windows 7.
http://php.net/manual/en/language.errors.php7.php
As the Error hierarchy does not inherit from Exception, code that uses
catch (Exception $e) { ... } blocks to handle uncaught exceptions in
PHP 5 will find that these Errors are not caught by these blocks.
Either a catch (Error $e) { ... } block or a set_exception_handler()
handler is required.
You can, additionally, catch (\Throwable $e) {} to account for both Error and Exception types.
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.
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.
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.
I am trying to understand what the best approach would be to handle Exceptions in the following scenario:
I have a class employee:
class employee extends person {
private $salary;
private $baseSalary = 6.5;
function __construct($f, $m, $l, $a,$fsalary=0){
if(!is_numeric($fsalary)){
throw new Exception("Age supplied is not a number", 114);
}
parent::__construct($f, $m, $l, $a);
$this->salary=$fsalary;
}
function GetDetails(){
return parent::GetName().
"<br/>".
$this->salary;
}
function __toString(){
return $this->GetDetails();
}
}
And using this:
try{
if(!$f = new employee("Sarah", "Sebastian", "Pira", "abc")){
throw new Exception();
}
else {
echo $f;
}
}
catch (Exception $e){
echo "<br/>";
echo var_dump($e);
}
Now I would think it would be a good idea to throw an exception in the class and then use just one catch block in all the scripts that would be using an employee object - But this doesn't seem to work - I need to have a try catch block within the class - Is this the correct way of looking at this?
Thanks
I think what you're saying is that you want to do something like this:
try {
class Employee extends Person {
// ...blah blah...
}
}
catch(Exception $e) {
// handle exception
}
...and then be able to insantiate it in other classes, without explicitly catching any exceptions:
// try { << this would be removed
$employee = new Employee();
// }
// catch(Exception $e) {
// (a whole bunch of code to handle the exception here)
// }
You can't do that, because then the try/catch block in the class will only catch any exceptions that occur when defining the class. They won't be caught when you try to instantiate it because your new Employee line is outside the try/catch block.
So really, your problem is that you want to be able to re-use a try/catch block in multiple places without re-writing the code. In that case, your best solution is to move the contents of the catch block out to a separate function that you can call as necessary. Define the function in the Employee class file and call it like this:
try {
$employee = new Employee();
$employee->doSomeStuff();
$employee->doMoreStuffThatCouldThrowExceptions();
}
catch(Exception $e) {
handle_employee_exception($e);
}
It doesn't get rid of the try/catch block in every file, but it does mean that you don't have to duplicate the implementation of the exception-handling all the time. And don't define handle_employee_exception as an instance method of the class, do it as a separate function, otherwise it will cause a fatal error if the exception is thrown in the constructor because the variable won't exist.
You should read more about Exceptions in PHP.
You can handle exceptions within the methods of the class, sure. But you should rethink how you want to do this and... why.
Good practice is also creating own exception class, so you are able to distinguish exceptions thrown by your module / class from the exceptions thrown by something else. It looks like that (see more):
class EmployeeModule_Exception extends Exception {}
and when it comes to throwing exception:
// the second parameter below is error code
throw new EmployeeModule_Exception('some message', 123);
Catching is similar, only the below example will catch only your module's exceptions:
try {
// some code here
} catch (EmployeeModule_Exception $e) {
// display information about exception caught
echo 'Error message: ' . $e->getMessage() . '<br />';
echo 'Error code: ' . $e->getCode();
}