close Warning: Can't synchronize with repository "(default)" (/project/cl-weblocks/svn does not appear to be a Subversion repository.). Look in the Trac log for more information.

Opened 11 years ago

Closed 10 years ago

#6 closed enhancement (fixed)

Handling and reporting errors

Reported by: sakhmechet Owned by: sakhmechet
Priority: medium Milestone: 0.2
Component: weblocks Version: pre-0.1
Keywords: error handling failure Cc:


Currently when errors occur on AJAX requests (in both debug and release) there is a simple JavaScript popup. When errors occur on regular requests (in release) there is a plain old error 500 page.

We need to show debug information on AJAX requests in debug mode. Should we modify the popup (perhaps redirect to error page) when an error occurs on AJAX requests in release? For regular requests we need a prettier error page.

We also need special handling of session timeout errors. When a session times out we should probably refresh the page and show a popup/flash saying a new session has been created.

Change History (3)

comment:1 Changed 10 years ago by sakhmechet

  • Milestone changed from 0.1 to 0.2

comment:2 Changed 10 years ago by sakhmechet

Ok, the following four aspects need to be worked out:

  1. A customized error page on regular requests in release mode.
  2. Properly presenting errors and stack traces on AJAX requests in debug mode (instead of session timeout popup).
  3. Properly presenting errors on AJAX requests in release mode (perhaps "an error occurred" popup is sufficient).
  4. Dealing with true session timeout errors.

The first aspect can be solved via hunchentoot's *http-error-handler*. Perhaps weblocks should provide a wrapper interface for this.

The second aspect can be solved by dumping a full stack trace to the pop up box. This will involve informing the JS frontend whether we're in release or debug mode. I'm not completely sure how to do that. Perhaps include an extra debug-weblocks.js file on release mode?

The third aspect pretty much works as intended today. I'm not sure if anything needs to be done here, perhaps an automatic refresh once the user hits "OK" in the JS popup?

The fourth aspect (actual session timeouts) seems fairly easy to handle. Instead of signalling a simple-error (like weblocks does today in request-handler.lisp:43), it can signal a special condition (session-timeout, etc.). The default handler can simply redirect to the root URL '/', while a customized handler can take a different action (redirect to another URL, etc).

What do you think?

comment:3 Changed 10 years ago by sakhmechet

  • Resolution set to fixed
  • Status changed from new to closed

Fixed, aside from the customized error page on regular requests in release mode. This bit is really separate from this enhancement, thefore closing.

Note: See TracTickets for help on using tickets.