Error handling in PHP with custom IDs and custom messages - php

Question

I'm on a project where I don't want to throw errors directly at the user. Instead I want customized messages for the error that accur.
For later I also need to keep an error number in order to customize the error messages from outside the class, like an array of error messages.
So I made my own thing where I set $error = null and then later set error to a number that later becomes a message.
Question
Is there any disadvantages with this approach? Am I better of with try/catch or something else? I would like to keep the code short and tidy if possible.
In this short code example the error handling seems to be a big part of the class. In my real code which is a few hundred lines, it's not a big part of the whole code
http://sandbox.onlinephpfunctions.com/code/623b388b70603bf7f020468aa9e310f7340cd108
<?php
class Project {
private $error = null;
public function callMeFirst($num) {
$this->nestedLevelOne($num);
$this->nestedLevelTwo($num);
$this->setResults();
}
public function callMeSecond($num) {
$this->nestedLevelTwo($num);
$this->setResults();
}
private function nestedLevelOne($num) {
// Do stuff
if($num !== 1) {
$this->error = ['id' => 1, 'value' => $num];
}
}
private function nestedLevelTwo($num) {
// Do stuff
if($num !== 20) {
$this->error = ['id' => 2, 'value' => $num];
}
}
private function message($args) {
extract($args);
$message = [
1 => "Nested level one error: $value",
2 => "Another error at level two: $value",
];
return ['id' => $id, 'message' => $message[$id]];
}
private function setResults() {
$results['success'] = ($this->error === null) ? true : false;
if($this->error !== null) {
$results['error'] = $this->message($this->error);
}
$this->results = $results;
}
}
$project = new Project();
$project->callMeFirst(1);
$project->callMeFirst(2);
print_r($project->results);
It will output
Array
(
[success] =>
[error] => Array
(
[id] => 2
[message] => Another error at level two: 2
)
)
The reason I'm asking is that I have a feeling of that I may reinvent the wheel in this case. Am I?
If there is a better solution, I would be thankful to see how that code looks like.

Answer 1

I would probably separate the business logic from the error handling to simplify each part more. By using exceptions, you keep your business logic simpler; you simply throw an exception whenever you encounter a case that is not permitted, thereby preventing getting into any sort of inconsistent state at all. The business logic class doesn't have to care about how this error will be processed further, it just needs to raise the error. You should then create a separate wrapper around that business logic class which simply cares about handling any errors and formatting them into an array or other sort of response which will be handled elsewhere. Something along these lines:
class ProjectException extends Exception {
public function __construct($num) {
parent::__construct(get_called_class() . ": $num");
}
}
class NestedLevelOneException extends ProjectException {
// customise __construct here if desired
}
class NestedLevelTwoException extends ProjectException {}
class Project {
public function callMeFirst($num) {
$this->nestedLevelOne($num);
$this->nestedLevelTwo($num);
}
public function callMeSecond($num) {
$this->nestedLevelTwo($num);
}
protected function nestedLevelOne($num) {
if ($num !== 1) {
throw new NestedLevelOneException($num);
}
// do stuff
}
protected function nestedLevelTwo($num) {
if ($num !== 20) {
throw new NestedLevelTwoException($num);
}
// do stuff
}
}
class ProjectService {
protected $project;
public function __construct(Project $project = null) {
$this->project = $project ?: new Project;
}
public function process($a, $b) {
try {
$this->project->callMeFirst($a);
$this->project->callMeSecond($b);
return ['success' => true];
} catch (ProjectException $e) {
return ['success' => false, 'error' => $e->getMessage()];
}
}
}
$api = new ProjectService;
print_r($api->process(1, 2));
By defining three separate exceptions, you get a lot of flexibility in how and where you want to handle errors. You can specifically catch NestedLevel*Exception, or you catch either of them with ProjectException.
By having your methods throw exceptions, you gain flexible error handling possibilities. You are free to not catch the exception and have the program terminate, as would be entirely reasonable if one of your business requirements isn't met. Alternatively, you can catch the exception at a level up that is prepared to deal with that error and turn it into something meaningful that can be acted upon.
By moving the generation of the error message into the exceptions, you keep the error type and its message self-contained. There's exactly one place where you define what kind of error may happen and what its error message will look like; instead of spreading that out over your entire codebase. And you're still free to choose some other error message in the UI, e.g. for localising different kinds of errors into multiple languages; just check the type of the exception object.
By using a separate ProjectService which cares about handling those exceptions and turning it into an array response, you narrow each class' responsibilities and make each class more flexible and simpler.