When request method is unsupported

[roman]

When a request method unsupported by the framework or application comes in, what do you think should happen? Currently, the framework produces a warning and notice message:

Warning: Invalid argument supplied for foreach() in C:\Users\[user name]\Documents\Dev\Web\Sites\IssueTracker\dooframework\uri\DooUriRouter.php on line 271

( ! ) Notice: Uninitialized string offset: 0 in C:\Users\[user name]\Documents\Dev\Web\Sites\IssueTracker\dooframework\uri\DooUriRouter.php on line 397

I think this situation should produce an exception so that an app could deal with that situation gracefully. I'd also like a default action taken, along the lines of what we have discussed before -- a default action with a possibility to change it by the user of the framework.

[leng]

roman, for unexpected errors it is best to utilized the web server settings. In apache we have ErrorDocument, if we have PHP display_error off, any php errors/exception will create a 500 error status and it can be handled by the web server. It is commonly used in web production. Besides most web servers only supports a few standard request type, If you need all just use * in the routes.

Code: Select all

ErrorDocument 400 /errors/badreq.html
ErrorDocument 401 /errors/noauth.html
ErrorDocument 403 /errors/forbid.html
ErrorDocument 404 /errors/missing.html
ErrorDocument 500 /errors/conferr.html

[leng]

If you need it to be handle by PHP, you can also redirect people off to an URL.

Code: Select all

ErrorDocument 500 http://www.mydomain.com/error/

[roman]

I just used error_reporting(0) to turn off error reporting on my local server, but that didn't have an effect, for some reason. The messages were still displayed, and these messages displayed some internal details. What this tells me is that my applications will depend upon settings made by admins of my hosting provider. If they mess up in a certain way, some implementation details will be displayed to the user, and I don't want that.

To void situations like the one above, I will have to compare current request method to those my app is prepared to deal with, and handle exceptions myself. This is an extra thing I'll have to do, but I'd prefer the framework to handle it to reduce amount of work I have to do. This seems a clear case for throwing an exception: an app is not programmed to handle the incoming request. Handling it in the app or framework will make it more portable. Otherwise, if the app is moved to another server, more things will have to be done to configure the server.

[leng]

You can catch the errors in index.php and send it to a error route to handle display a general error message.

Code: Select all

try{
    Doo::app()->run();
}catch(Exception $e){
    //redicrect to the error route defined in routes.conf.php
    $_SERVER['REQUEST_URI'] = '/error/';
    Doo::app()->run();
}

I think a general message will do as the users doesn't need to know what kind of error. However you can catch PDOException if you feel to show users that it's a database error.

[leng]

For PHP errors/warnings/etc instead of exception you can use set_error_handler in index.php

Code: Select all

set_error_handler("handleError");
function handleError(){
    //redirect to the error page when error occur!
    //Or you can log it.
    header("Location: /error/",404);
}

Hence even with display_error on in your situation you can still redirect the errors to a page to display them.

[leng]

If you would like to know more, there's a good article here http://www.derekallard.com/blog/post/er ... deigniter/

[roman]

Thanks for all the info. I will study it. But the following won't work for the situation I started this thread with:

Code: Select all

try{
    Doo::app()->run();
}catch(Exception $e){
    //redicrect to the error route defined in routes.conf.php
    $_SERVER['REQUEST_URI'] = '/error/';
    Doo::app()->run();
}

The framework doesn't throw an exception in the case that currently concerns me, and making it throw an exception is the essence of my request here.

[leng]

The only thing that throws Exception from the framework is DooSqlMagic as DB is more unpredictable.
As for the other features/classes, as long as you follow the accepted parameter values it will be fine.

[leng]

BTW, in what situation does the URIRouter failed to process that request of yours which output the errors in your first post?