How to avoid users getting 500 errors when excluding server
The following errors appear in my server log.
- 2012-03-06 09:20:43 HTTP JVM: CLFAD0211E: Exception thrown. For more information, refer to the error-log-0.xml located in the D: / Lotus / Domino / data / domino / workspace / logs folder
- 2012-03-06 09:20:43 HTTP JVM: CLFAD0229E: A security exception caused a service request for: /demo.nsf/home.xsp - HTTP code: 500. For more information, see Error-log - 0.xml located in D: / Lotus / Domino / data / domino / workspace / logs
The user only sees this in the web browser (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 from the server log that there is a security exception on the server, possibly because I have incorrect settings in my java.policy file. but my problem is not what is causing the error, but how can I avoid users getting those ugly 500 errors.
I would like the error page that I have set in the application to be presented to the user exactly like any other exception.
possibly?
source to share
The more try / catch blocks you have in your code, the better (within reasonable limits, of course):
try {
// code that might throw an error
} catch (e) {
// examine the error to see if there a workaround
// if not, log it and inform the user
} finally {
// any code that needs to run whether or not there was an error
}
That way, if something fails, it fails gracefully. Just remember to make it obvious to the user that something went wrong (and preferably provide them with instructions that they can actually follow) ... the failure is silent, even worse than an ugly error page if something went wrong and the user thinks everything was fine.
PS As Stefan points out, there are some bugs that simply cannot be caught. Unless the XPage was signed by someone with access to run XPages, for example, it doesn't even get to the point of trying to run your code ... the page itself is invalid, so you can't do anything at runtime. Always make sure your XPages are signed during deployment.
source to share
There are a number of errors that "break through" even if you have an error page. For example. when you drag the control onto yourself. Security is another area. These are all things that you must handle during development. I have not seen errors that "normally" happen (true runtime after development is complete and type of errors tested) while avoiding the custom error page. Beyond that, follow Declan's advice.
source to share
I also had a problem where my error page was not displayed and an error page was displayed instead.
I found that there was a problem on my error page as well, and so the render fails to display the error for the original page, and instead you get the default error page.
The best way to check if this is the cause of your particular problem is to start with a simple error page, no theme, no ssjs libraries, no ssjs code on the page, etc., just a blank x-page with some static text, so that indicate that this is an error page.
Once you can confirm that this is a possible cause of the 500 error, you can start building this error page and add dynamic material piece by piece until you need it.
source to share
Dmytro Pastovenskyi has a good article http://dpastov.blogspot.com/2012/01/error-pages-in-domino.html about errors in Domino.
To be on the safe side, I have a static html page with the message "An error occured". This page is referenced by the HTTPMultiErrorPage parameter in notes.ini on your server.
Then there is a rule for HTTP response headers addressed to special error codes.
The main problem is that these are global settings. Thus, there is no easy way to catch all errors specifically for your application. But at least the user doesn't get this nasty white error page.
source to share
I had similar problems. Error messages are caused by some underlying error that overrides a specific error page for the application. This is bad behavior (from a user perspective) and makes you feel a little naked. I understand that it is difficult for an application to trap them, but at least there must be a way to customize this message. By default, this 500 page is not very useful for the average user ...
The only way (?) To avoid your code throwing an error like this (ssjs / java) is (as Tim Triconkin already mentioned), to always use try / catch arguments around the code (as you already know :))
getDocumentByUNID () is a "good" example of a method that will render the ugly (but standard) 500 error page instead of the one defined in the application.
As with any other error types (system / security, etc.) - I don't think it is possible to redirect them to the error page of the applications being called (by user), because they are not called from the application, but rather the application (I hope i'm wrong).
source to share
Create a new XPage named error.xsp (for example). Put some basic information here that something went wrong, apologize for that fact and give some links on how to proceed (although his / her data may be lost forever - history.go (-1) usually does not solve the problem). In the background, you can log the error (OpenLog is recommended).
Open Application Properties, XPages tab. Clear the Show XPage error page check box . On the Error page, select the (error) page.
source to share