Hello
(Is axkit-devel the right place for discussing this? I've been unsubscribed for about half a year so don't know the current state on this list.)
The exception handler code (for using error stylesheets) in axkit has two deficiencies:
1) exceptions thrown before main_handler (fast_handler or handler) are not catched. This means that for example if an xml file has inproper encoding, the resulting LibXML exception is not converted and leads to the normal "internal server error", with the exception message only written to the log.
2) exceptions not belonging to a class known to axkit are not formatted either.
The attached patch solves both problems. It's certainly in an unfinished state, but I need feedback, I can't find out all those many peculiar details myself.
General idea:
- wrap the code in both fast_handler and handler into an eval, and then process the $@, if needed. Thus I've removed the whole exception decision tree from main_handler and put it into a new subroutine do_process_error.
One thing I've just realized: I've uncommented the local $SIG{__DIE__} stuff, since it looked like it was just disturbing and needless since I'm formatting classless exceptions myself anyway now. But I've now realized that prolly the __DIE__ stuff is useful *for getting (even structured) backtraces* of all exceptions. So this should go back of course.
- One remaining problem is that of wrongly encoded strings: since I don't (and can't) know what the exception contents are encoded in, I now simply remove all 8bit chars. Maybe a function trying to find out the encoding with some best guesses would be useful, dunno if that already exists somewhere.
- The "<error><msg>...</msg></error>" string I first tried just didn't want to be formatted. I've always got "<html><body></body></html>" in the browser, while my stylesheet really asks for a stylesheet that *can't* output that string!. so ?? from my part, and I just output html directly. Well, $p->print does'nt do it's duty either, (im not a mod_perl hacker), thus the strange custom_response stuff.
Thanks for feedback and cheers Christian.
%axkit_exception_horror.patch
Description: application/applefile
axkit_exception_horror.patch
Description: Binary data