Bug Report #4695

Kohana_Exception handlers

Added by Eugene Alright about 1 year ago. Updated 9 months ago.

Status:ClosedStart date:02/03/2013
Priority:NormalDue date:
Assignee:Lorenzo Pisani% Done:


Target version:3.3.1
Resolution:wontfix Points:1


There is definitely something wrong with this piece of code (look at pic in attachments). Second handler is public, but named with underscore before name, like it says it is a protected one. And it's getting even more confusing when I try to override the handler. Which one should I use?

2731be45e89c412572599b2dc4c558da10a37cfd.png (31.7 KB) Eugene Alright, 02/03/2013 06:03 PM

kohana-exception.png (16.6 KB) Eugene Alright, 02/05/2013 07:10 PM


#1 Updated by Jeremy Bush about 1 year ago

There's nothing wrong here. You should read the docs on implementing custom http exceptions: http://kohanaframework.org/3.3/guide/kohana/tutorials/error-pages

#2 Updated by Eugene Alright about 1 year ago

Well, I've read the docs earlier. But I thought that with implementing get_response method in the main HTTP_Exception class, Kohana will convert all uncatched exceptions into HTTP_Exception, so it's will show a response that I want ("Oops" page).
But it seems it doesn't work this way. Instead, I have to do some work in Kohana_Exception class, which is a parent for all other classes. You can see in attachments what I did there. What am I doing wrong?

#3 Updated by David Chan about 1 year ago

I am having a similar problem.

I overrode HTTP_Exception::get_response to display a custom error page, and I use HTTP_Exception_XXX throughout my code for user errors (as opposed to developer errors)

However I noticed that HTTP_Exception has a special catch block in Kohana/Request/Client.php which does not use Kohana_Exception::handler()

Unfortunately when I throw exceptions from Route::Filter methods I am not yet within the scope of this special catch, and I do not see my expected custom error page.

This is important because my project is a RESTful API and I must return the proper HTTP error code 400, etc

but when I return false instead of throwing an error in my Route::Filters I always get a 404.

#4 Updated by David Chan about 1 year ago

I have a patch which addresses my issue.


#5 Updated by David Chan about 1 year ago

i added a new issue #4697 since my issue is not as similar as i first thought

#6 Updated by Lorenzo Pisani 12 months ago

  • Status changed from New to Assigned
  • Assignee set to Lorenzo Pisani
  • Target version set to 3.3.1

#7 Updated by Jeremy Bush 12 months ago

To me it sounds like you are using routes like controllers. I'm not sure why you would want to throw an HTTP exception inside a route filter.

#8 Updated by Robert-Jan Dreu -rjd22- 10 months ago

I think this should not be merged into the core. This is an edge case and since no other people are having the same issue this can be easily fixed by overloading it yourself.

#9 Updated by Lorenzo Pisani 10 months ago

He is right about 404 not always being a correct response though. If a route matches POST, GET, and PUT, a DELETE on that same resource should be a 405 and return the allowed methods. Is the proper way to handle this to simply match all methods and stub out an action in the controller that simply throws a 405? This basically means that if you want an endpoint that only accepts GET requests, you need to stub out all the other request methods or have a catch-all.

public function action_delete_entity()
    throw HTTP_Exception::factory(405)->allow(…);

I suppose you could use a route filter to match unsupported methods and send them all to action_405().

#10 Updated by Lorenzo Pisani 9 months ago

  • Status changed from Assigned to Closed
  • Resolution set to wontfix

Closing this and will work on improving this in 3.4.0 with #4697.

Also available in: Atom PDF