quetz-mod_python-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Dumpleton <grah...@dscpl.com.au>
Subject Re: Changes to what is displayed when handler exception occurs.
Date Fri, 27 Oct 2006 22:10:33 GMT

On 27/10/2006, at 11:08 PM, Dan Eloff wrote:

>> I know we have talked a bit before about providing a means of  
>> allowing people
>> to return custom error pages and I haven't forgotten that. The  
>> cleanup of the
>> code and working out what the report error function should take in  
>> the way of
>> arguments is a first step to seeing how the ability to override it  
>> could be
>> done.
>
> True
>
>> Anyway, comments most welcome. Is there any other basic  
>> information that
>> should perhaps be included in such a page. For example, the name  
>> of server
>> or virtual host etc. I don't want to include stuff which is too  
>> obvious though.
>
> It looks good, although I wouldn't want to write an exception handler
> taking that many arguments. It would be best to put them all in a
> special object and pass the request and that object (or attach one to
> the other).
>
> I can think of one thing that might be helpful to know, but I'm not
> sure how easy it would be to get (or how valuable it would be.) I'll
> throw it out there so you can think about it.
>
> If PythonAutoReload is on, it would be nice to know how old
> (days:hours:minutes:seconds) the handler module is (measure by when it
> was last reloaded), and the same for the module that raised the
> exception (if different, or as close to it as possible if it occurred
> in a module not managed by the importer), excepting modules not loaded
> by your importer. Additonally, the names of all modules that failed a
> call to __mp_clone__ (you would have to save that information ahead of
> time, probably use a set)
>
> At a glance that would tell you:
> If your module was reloaded since you changed it
> If your module was reloaded unexpectedly
> If any modules failed to pass on their state when reloaded
>
> I've encoutered a number of situations where one of those was
> responsible for the problem, or one of those was suspected and had to
> be eliminated as a cause of the problem. You will have to weigh the
> difficulty in implementing it versus the estimated worth to the
> average user, however.

I'll have a think about it. I certainly keep load times and  
modifications times in
the cache, plus a sequence number representing the overall version of  
the
full set of modules loaded.

Like I provide a function for generating a DOT graph, it may be nice  
to have
another helper function which dumps out a lot of other information  
out about the
cache. Ie., all modules loaded, load times, modification times etc  
etc. This
could be triggered as a handler in its own right, or by way of an  
option flag
included in the bottom of a exception page. The only problem with  
having it
as a separate handler on its own URL is that its a separate access so  
have
to deal with it going to a different Apache child process etc. Still  
may be
useful though.

Not sure about __mp_clone__/__mp_purge__ errors. They are at least
logged now. :-)

Graham

Mime
View raw message