I'm used to Zend Framework, when you write your own component, you make it's own Exception file, but on per file basis, then you have such structure:
Zend/View/Exception.php
Zend/View/Helper/Exception.php
Zend/View/Renderer/Exception.php
etc.
I'm ok with, I also use Doctrine2 and Exception are "stored" in a different way
something like (in a Zend way)
and in Zend/View/Exception.php
class Exception {
public static function invalidArguement() {
return new self('Invalid arguement was given, etc..');
}
I understand that the second approach is less flexible but more accurate because it throws exception according the error.
The first approach is just a way to be able to throw a Zend_View_Exception with a custom messagE.
Also, what about one Exception file per, Exception.
Like the following structure :
Exception/InvalidArguement.php
Exception/AuthentificationFailed.php
Exception/QuantityLimit.php
Is there any best practices? Any pros/cons?
For me the best practice is to group exceptions related to their issue.
For example if you have a number of Auth exceptions, like InvalidDetails, UserNotFound put them here
Library/Auth/Exceptions/InvalidDetails.php
Library/Auth/Exceptions/UserNotFound.php
Each exception should be an extension of Zend_Exception ( unless you've extended it yourself )
this way you can do:
throw new Library_Auth_Exception_InvalidDetails("Invalid details when trying to login");
the benefit of using this method is you DONT need to have a message, the Exception name can cover it enough.
My assumptions here is you setup a namespace for Library called Library and everything is within there.
I tend to group everything, so a typical Auth library could be:
Auth/Forms/Login.php
Auth/Exception/InvalidUser.php
Auth/Orm/Abstract.php
Auth/Orm/Doctrine.php
HTH
I've never worked with Zend framework but if this at all helps, I would at least make a common Exception class and all those other ones extend that rather than just make one for each.
Related
I want to use the Respect/Validation library in PHP. I know how to use it but currently I'm using it in a project in German language and of course, I also want the error messages in German.
For language translation, there is a section in the documentation but I don't really get it and I did not found any answer yet.
They're talking about a translator that should handle the translation of the messages. As a second parameter they're giving "gettext" but I don't know what this should be and how this should handle the translation.
Can anybody explain me how this works?
Respect/Validation won't do the translation for you, you should use a different project, library or function to do that. It won't leave you empty handed though, as the documentation states.
First, you should try to understand how translation libraries work (such as gettext()) and then read PHP documentation on Callables. Then it is a matter of choosing a library, creating the translations and calling setParam('translator', 'callable') method on the exception instance.
A quick introduction to your problem:
Translations are done based on a source: it can be a file, a database or something else, depending on which library you use.
Respect/Validation exception messages use the same pattern: {{name}} is invalid.. Where {{name}} will be replaced by the input given or the name if setName() was called on that rule.
You can see all messages you need to translate under the Respect\Validation\Exceptions namespace.
Usually, every library provide a single function/method to translate a given string. This is the method/function you want to set on the $exception->setParam() call.
If you ever translate all exception messages, we would love to make them available to everyone else.
PS: You could also make this question on the repository page, more people would help and we could also improve the way translations are handled by the library in the future.
I just changed all Exception defaultTemplates property, it works for me.
class Localization
{
public function init()
{
$this->validation();
}
public function validation()
{
$prefix = '\\Respect\\Validation\\Exceptions\\';
$localize = [
'EmailException' => 'local message',
'NotEmptyException' => 'local message'
];
foreach($localize as $class => $message) {
($prefix.$class)::$defaultTemplates[
ValidationException::MODE_DEFAULT][ValidationException::STANDARD] = $message;
}
}
}
$localization = new Localization();
$localization->init();
I just discovered SensioLabsInsight and found very interesting tips on how to write good code. It would be great if there was some explanation on why (or why not) something should be used - even for basic stuff like exit and die. It would help me to explain things to people I work with.
So my question is specifically for AccessDeniedHttpException - it says:
Symfony applications should not throw AccessDeniedHttpException
So how do I return 403 Forbidden from the application controller or EventListener?
What is the best practice?
To be honest I thought it would be
throw new AccessDeniedHttpException()
Since for 404 you have
throw $this->createNotFoundException()
But it looks like I was wrong.
I think it means that you must throw AccessDeniedException instead of directly throwing AccessDeniedHttpException.
Main reason is that AccessDeniedException is catched by the event listener in Symfony\Component\Security\Http\Firewall\ExceptionListener and then you can make some stuff with it. Check onKernelException function.
That sentence has to be considered with the whole architecture of Symfony in mind.
In the Symfony framework there is a whole subsystem devoted to security applying the 2 step Authentication + Authorization process.
That said in the architecture of Symfony the Controllers, that are what basically the framework leaves to you to develop and so they are "the application", will be called only if the Authentication + Authorization has been passed.
So that sentence say that you should not need to throw that Exception becouse that is the work for the Security component. Doing that it is not forbidden or even made impossible but it is not the way which the framework has been normally thinked to work.
This can happen in two situations:
Your application is particular and you need to do that way
You are doing the security work out of the framework way of doing. It is your choice, just evaluate cost/benefits of not using the framework features and write your own ones.
Looking here http://symfony.com/doc/current/cookbook/security/custom_authentication_provider.html it seems like you might be able to throw an AuthenticationException which returns a 403 Response (?)
Here is Controller::createNotFoundException() implementation:
public function createNotFoundException($message = 'Not Found', \Exception $previous = null)
{
return new NotFoundHttpException($message, $previous);
}
It throws a bit different exception.
I don't know the reason for this tip. Maybe its because in controller or event listener You can directly return the Response, without throwing exception and thus triggering other event listeners.
Symfony uses event listeners to handle exceptions. You can create your own listeners and manage the response. Might be useful for API. For example I have used it to return pretty json responses in dev environment (with stack trace and additional debugging info).
So I wrote my PHP MVC framework, and have Dispatcher class that can instantiate appropriate Controller class and call defined method passing arguments.
Now inside Dispatcher I check if this Controller exists and if method exists, what should I do if controller or method does not exist?
At the moment I just return HTTP Object that prints 404 - Page not found.
But there is no way for me to customize this message from inside application, and I want to provide users a way to customize 404 messages without editing dispatcher.
Is a good way to go to always have Error controller that would get instantiated when there is a error, and that would load lets say Error404.html view file?
So users would be able to customize this view file to fit their application design.
Is there any other way to achive this? And what would be the best way to return error from dispatcher, and let "users" or developers that are working on that MVC to easily customize 404 and other messages?
Thanks!
Since i do not know your API, I am going to guess. Lets assume that you have a bootstrap stage in your application, when the dispatcher is actually used. Something like:
$dispatcher->dispatch( $request );
Then for handling request, that try to access non-existent controllers or methods within those controllers, you can do something like this:
try
{
$dispatcher->dispatch( $request );
}
catch ( ClassNotFoundException $e )
{
$dispatcher->dispatch( new Request('/error/404/controller'));
}
catch ( MethodNotFoundException $e )
{
$dispatcher->dispatch( new Request('/error/404/method'));
}
The ClassNotFoundException can be thrown by your classloader, while dispatcher itself would always be responsible for throwing the MethodNotFoundException.
You can check, whether controller has a particular method, with method_exists(), before executing it in your dispatcher.
P.S. in my humble opinion, the Dispatcher conept is better suited for event driven architectures and not for MVC-inspired patterns in web applications.
I would propose you have an error controller that takes in an error code (number or string) as an argument. This allows you to gracefully handle various kinds of errors and be able to provide a stack trace if necessary. You can even utilize this work for 500 errors.
My answer comes with the assumption that a controller can return various actions and each action can have it's own template.
Symfony also seems to handle errors in a similar fashion. They have a separate module and action for each error.
sfContext::getInstance()->getController()->forward(sfConfig::get('sf_error_404_module'), sfConfig::get('sf_error_404_action'));
I'm working on a class-based php web app. I have some places where objects are interacting, and I have certain situations where I'm using error codes to communicate to the end user -- typically when form values are missing or invalid. These are situations where exceptions are unwarranted ( and I'm not sure I could avoid the situations with exceptions anyways).
In one object, I have some 20 code numbers, each of which correspond to a user-facing message, and a admin/developer-facing message, so both parties know what's going on. Now that I've worked over the code several times, I find that it's difficult to quickly figure out what code numbers in the series I've already used, so I accidentally create conflicting code numbers. For instance, I just did that today with 12, 13, 14 and 15.
How can I better organize this so I don't create conflicting error codes? Should I create one singleton class, errorCodes, that has a master list of all error codes for all classes, systematizing them across the whole web app? Or should each object have its own set of error codes, when appropriate, and I just keep a list in the commentary of the object, to use and update that as I go along?
Edit: So I'm liking the suggestions to use constants or named constants within the class. That gives me a single place where I programatically define and keep track of error codes and their messages.
The next question: what kind of interface do I provide to the outside world for this class' error codes and messages? Do I do something like triggerError(20) in the class, and then provide a public method to return the error code, the string constant, and the user- and admin-facing message?
You could create a couple of defines to create named constants for all your error codes :
define('ERROR_CODE_SQL_QUERY', 1);
define('ERROR_CODE_PAGE_NOT_FOUND', 2);
define('ERROR_CODE_NOT_ALLOWED', 3);
// and so on
And, then, use the constants in your code :
if ($errorCode == ERROR_CODE_SQL_QUERY) {
// deal with SQL errors
}
With that, nowhere in your code you'll use the numerical value : everywhere (except in the on and only file where you put the defines), you'll use the codes.
It means :
Less risk of errors, as all numerical values are set in only one file
Less risk of errors, as you'll use the constants, that have a name which indicates what it means
And code that's easier to read.
Another idea could be to create a class to deal with errors :
class Error {
const CODE_SQL_QUERY = 1;
const CODE_PAGE_NOT_FOUND = 2;
const CODE_NOT_ALLOWED = 3;
// Add some methods here, if needed
}
And, then, use something like this :
if ($errorCode == Error::CODE_SQL_QUERY) {
// deal with SQL errors
}
Which one is the best ?
It's probably a matter of personnal preferences... If you need to add some methods to deal with the errors, using a class might be useful. Else, defines are a great solution too.
At the very least, can you bump the code numbers up to be class constants or members?
class MyErrorProneClass {
const TURNED_INTO_A_NEWT = 12;
...
public function dontBurnMe() {
// echo your error here using self::TURNED_INTO_A_NEWT
}
This way you can manage the errors in the same place where you use them, rather than having to maintenance a large central file. I tried something to that effect in the past and it becomes difficult to keep up.
Generating error numbers programmatically may be a better long-term solution. If you could use information about the file or line number (__FILE__ and __LINE__ respectively), that would help.
Hope that moves in the right direction at least.
Thanks, Joe
Edit:
A class member would follow this syntax instead:
class MyErrorProneClass {
protected static $turnedIntoANewt = 12;
...
public function dontBurnMe() {
// echo your error here using self::$turnedIntoANewt
}
Since constants are public by default, you can access them from other classes directly if you want. So, from the outside, the error would be referenced as:
MyErrorProneClass::TURNED_INTO_A_NEWT
For associating to messages, you would use a mapping (either in a database, or in some localization file) from error ID (and frontend/backend) to displayed string. This use of keys for messages isn't optimal, but it would allow you to change error messages without changing code as well.
If you don't know already it might be an idea to use trigger_error (), plus an error handler if you want to present the user with a better error message.
Have you thought about using exceptions? They may be a good choice for your problem here although adding them to your project now would probably require some restructuring.
You can extend the basic exception class so it fits your problem in terms the of user / developer error message separation.
How should I write error reporting modules in PHP?
Say, I want to write a function in PHP: 'bool isDuplicateEmail($email)'.
In that function, I want to check if the $email is already present in the database.
It will return 'true', if exists. Else 'false'.
Now, the query execution can also fail, In that time I want to report 'Internal Error' to the user.
The function should not die with typical mysql error: die(mysql_error(). My web app has two interfaces: browser and email(You can perform certain actions by sending an email).
In both cases it should report error in good aesthetic.
Do I really have to use exception handling for this?
Can anyone point me to some good PHP project where I can learn how to design robust PHP web-app?
In my PHP projects, I have tried several different tacts. I've come to the following solution which seems to work well for me:
First, any major PHP application I write has some sort of central singleton that manages application-level data and behaviors. The "Application" object. I mention that here because I use this object to collect generated feedback from every other module. The rendering module can query the application object for the feedback it deems should be displayed to the user.
On a lower-level, every class is derived from some base class that contains error management methods. For example an "AddError(code,string,global)" and "GetErrors()" and "ClearErrors". The "AddError" method does two things: stores a local copy of that error in an instance-specific array for that object and (optionally) notifies the application object of this error ("global" is a boolean) which then stores that error for future use in rendering.
So now here's how it works in practice:
Note that 'Object' defines the following methods: AddError ClearErrors GetErrorCodes GetErrorsAsStrings GetErrorCount and maybe HasError for convenience
// $GLOBALS['app'] = new Application();
class MyObject extends Object
{
/**
* #return bool Returns false if failed
*/
public function DoThing()
{
$this->ClearErrors();
if ([something succeeded])
{
return true;
}
else
{
$this->AddError(ERR_OP_FAILED,"Thing could not be done");
return false;
}
}
}
$ob = new MyObject();
if ($ob->DoThing())
{
echo 'Success.';
}
else
{
// Right now, i may not really care *why* it didn't work (the user
// may want to know about the problem, though (see below).
$ob->TrySomethingElse();
}
// ...LATER ON IN THE RENDERING MODULE
echo implode('<br/>',$GLOBALS['app']->GetErrorsAsStrings());
The reason I like this is because:
I hate exceptions because I personally believe they make code more convoluted that it needs to be
Sometimes you just need to know that a function succeeded or failed and not exactly what went wrong
A lot of times you don't need a specific error code but you need a specific error string and you don't want to create an error code for every single possible error condition. Sometimes you really just want to use an "opfailed" code but go into some detail for the user's sake in the string itself. This allows for that flexibility
Having two error collection locations (the local level for use by the calling algorithm and global level for use by rendering modules for telling the user about them) has really worked for me to give each functional area exactly what it needs to get things done.
Using MVC, i always use some sort of default error/exception handler, where actions with exceptions (and no own error-/exceptionhandling) will be caught.
There you could decide to answer via email or browser-response, and it will always have the same look :)
I'd use a framework like Zend Framework that has a thorough exception handling mechanism built all through it.
Look into exception handling and error handling in the php manual. Also read the comments at the bottom, very useful.
There's aslo a method explained in those page how to convert PHP errors into exceptions, so you only deal with exceptions (for the most part).