How to avoid users getting 500 Errors when server throw exception

3
votes

I get the following errors in my server log.

  • 2012-03-06 09:20:43 HTTP JVM: CLFAD0211E: Exception thrown. For more detailed information, please consult error-log-0.xml located in D:/Lotus/Domino/data/domino/workspace/logs
  • 2012-03-06 09:20:43 HTTP JVM: CLFAD0229E: Security exception occurred servicing request for: /demo.nsf/home.xsp - HTTP Code: 500. For more detailed information, please consult error-log-0.xml located in D:/Lotus/Domino/data/domino/workspace/logs

The user only sees this in the webbrowser (source)

<html>
<head>
<title>Error</title></head>
<body text="#000000">
<h1>Error 500</h1>HTTP Web Server: Command Not Handled Exception</body>
</html>

So I can tell by the server log that there is a security exception thrown at the server, probably because I have wrong settings in my java.policy file. but my issue is not what is causing the error, but rather how can I avoid users getting these ugly 500 errors.

I would like the error page I have set in the application to be presented to the user just like any other exception.

possible?

6
securityexceptionerror-handlingxpages

6 Answers

5
votes

The more try/catch blocks you have in your code, the better (within reason, of course):

try {
 // code that might throw an error
} catch (e) {
 // examine the error to see if there's a workaround
 // if not, log it and inform the user
} finally {
 // any code that needs to run whether or not there was an error
}

This way if something fails, it fails gracefully. Just be sure to make it obvious to the user that something went wrong (and, preferably, provide them instructions they can actually follow up on)... failing silently is even worse than an ugly error page if something went wrong and the user thinks everything was fine.

P.S. As Stephan indicates, there are some errors that simply can't be caught. If the XPage wasn't signed by someone with access to run XPages, for instance, it never even gets to the point of trying to run your code... the page itself is invalid, so there's nothing you can do at runtime. Always make sure that your XPages are signed during deployment.

5
votes

There are a number of errors that "break through" even if you have an error page defined. E.g. when you drag a control onto itself. Security seems another area. All of them are stuff you should handle in development. I haven't seen errors that "typically" happen (true runtime after development completed and tested type of errors) escaping a custom error page. Other than that follow Declan's advice.

4
votes

I had an issue like this also where my error page was not being displayed and the error 500 page would display instead.

What I discovered is that there was a problem in my error page also and the renderer therefore can't display the error for the original page and you get the server default error page instead.

The best way to check if this is the cause of your particular issue is to start with a simple error page, no theme, no ssjs libraries, no ssjs code on the page etc, just a blank xpage with some static text to indicate that it is the error page.

Once you can confirm that this is the possible cause of the error 500 then you can start building up that error page and add in the dynamic stuff bit by bit till it is the way you need it.

2
votes

Dmytro Pastovenskyi has a good article http://dpastov.blogspot.com/2012/01/error-pages-in-domino.html about error pages in Domino.

To be on the safe side I have a static html page saying "An error occured". This page is referenced by the HTTPMultiErrorPage setting in the notes.ini on your server.

Then there is a "HTTP response headers" rule addressing special error codes.

The main problem still is, that these are global settings. So there is no easy way to catch all errors specially for your application. But a least the user don't get this annoying white error page.

1
votes

I have had similar issues with this. Error messages bubbling up from some underlying fault that overrides the defined error page for the application. This is not a nice behavior (from a user perspective) and makes you feel a bit naked. I do understand that it's hard for the application to trap those - but there should at least be a way to customize that message - The default error 500 page is not very useful for a normal user anyway...

The only(?) way to try to avoid that your code throws such error (ssjs/java) is to (as Tim Tripcony already mentioned) always use try/catch statements around the code (as you already know :))

getDocumentByUNID() is a "good" example of a method that will cause the ugly (but standard) error 500 page to be displayed instead of the defined one in the app.

As for any other error types (system/security and such) - I don't think it's possible to redirect those to the (by the user) invoked applications error page because they are not invoked from the application but rather before the application is invoked (I hope I'm wrong).

0
votes

Make a new XPage called error.xsp (for example). Put there some basic info that something went wrong, apologize for that fact and provide few links how to continue with the work (even though his/her data may be lost forever - history.go(-1) usually does not resolve the problem). In the background you can log the error (usage of OpenLog recommended).

Open Application Properties, XPages tab. Uncheck Display XPages runtime error page. In the combo Error page select your page (error).