Forum OpenACS Improvement Proposals (TIPs): Tip #32: (Rejected) Failure to Reload Watched Files Throws Error to the Page

Summary: When a watched file fails to reload, the APM should throw the error to the developer rather than catch it and copy it to the error log.

Why: You have just edited a file to add some functionality, you go to the page, reload the file and the functionality doesn't work.  Under the present system you need to decide if it failed because:

  1) your solution to the problem was wrong
  2) you made a typo in the page such as forgetting a }

Ruling out 2 requires switching to your display of the error log, and scrolling or searching back to the previous error.  In sites that are logging every db transaction and have multiple background processes, it g n take some time to confirm that all the watched files reloaded correctly.

If we throw the error to the screen, the developer is instantanously notified, can switch back to the file just edited and fix the bug that broke the file.

Why Not: It breaks the entire site until the file is fixed, developers can't use the web interface to debug the problem or search for functions.

Rebuttal: Better to find out about it sooner.  The worst case of having the file accidently propped to production and loaded on restart will break something and under much higher stress.

Its also unlikely that the web interface will be helpful in fixing the problem if its caused by a misplaced }.

  I am not familiar enough with the APM to say exactly how to implement it.  I don't imagine its more than a couple lines of code in the right file though.

Thank you,


You want to break the entire service over a typo? And you want to do this why? Because you don't want to look in the error log to find the load error?

An easy way to find the last error in the log file: open the error log in your favorite editor, go to the end, and search backward for 'error:'. You'll find it quickly.

Here's a scenario that you'll agree (I think) is bad:

You're working on putting some changes into the core (maybe you're even attempting to implement the change suggested by this TIP), and you make a mistake. The mistake you made just broke the APM, and it also affected the ability of the APM subsystem to load on startup.

What now? You do have a record of the initial the error log, and you're not going to see the APM UI (actually, any UI) until you fix the problem.

How are you going to fix the error? You're going to use the error log, except now that's *all* you have.

If you had used the error log in the first place, you'd still have an operational system while fixing the typo. Just don't stop the service in this state, it will not start again.


What if clicking on 'watch files' in the apm would result in not only marking them watched but also in an immediate reload of all affected files in the current thread for the sole purpose to find out if there were any errors in them, and if so display a warning in the apm UI?

Not sure if that's possible but the proc apm_source seems to be usable for that.

If that worked, we wouldn't need to change the request processors behaviour to achieve a more friendly dealing with reloads.

Rejected. Needs more discussion.

Tilmann, the file-watch.tcl page actually does an ad_returnredirect at the end, so it'll incur another page hit, and hence, a reload of the procs you just asked it to watch. So you don't need to call apm_source out of order.

The APM can easily record when sourcing a file fails. This information could then be output on the APM index page showing the watches, via developer-support on every page, or in a third way, if we can think of something clever.

I'm rejecting this TIP, however. Discussion should've taken place in the "Development" forum first, so we could've had a thought through TIP.


vetoed, needs further thinking.
I marked this rejected.  I think it's worth discussing how
to make errors in page reloading more visible, and we should
take that up in the dev forum.
There are two existing threads discussing this suggestion/request, both listed below. The first was the discussion prior to this TIP, the second sprouted (from this TIP) to further develop ideas and alternatives.