ShowTable of Contents
A simple error
Errors happen at various levels: syntax errors (which you should see before run time because they are flagged in the XPages editor); wrong class and method names, which are not caught at edit time; wrong calling sequences, which are not caught at edit time; and wrong input data at run time. These untreated conditions invariably result in Error 500.
What I find useful during development is to place suspect code in a
try ... catch statement and report the result to a Computed Field control on the XPage. In some cases, it may be useful to extend this model to the production code.
Here is code that displays the number of documents in a local database. The user specifies the database name to a request scope variable, for example, bound to an Edit Box or Combo Box control, and the script specifies the count to another request scope variable, for example, bound to a Computed Field.
var db:NotesDatabase = session.getDatabas(null, requestScope.dbname);
var dc:NotesDocumentCollection = db.getAllDocuments();
requestScope.dbccount = dc.getCount().toFixed();
However the script erroneously says
getDatabas instead of
getDatabase. The editor flags no error, your failing eyesight does not see it, and at run time you get the Error 500 page.
try ... catch
But place the code in a
try ... catch statement as shown below and bind
requestScope.status to another Computed Field on the page.
try {
var db:NotesDatabase = session.getDatabas(null, requestScope.dbname, false);
var dc:NotesDocumentCollection = db.getAllDocuments();
requestScope.dbcount = dc.getCount().toFixed();
} catch(e) {
requestScope.status = e.toString();
}
At run time, a meaningful message appears in the Computed Field bound to
requestScope.status:
Error calling method 'getDatabas(null, java.lang.String)'
on an object of type 'lotus.domino.local.Session
[Static Java Interface Wrapper, lotus.domino.local.Session: lotus.domino.Session]
The above code, with
getDatabase repaired, is useful to catch true run-time errors like bad user input for the database name. In the case of a bad database name, the following message appears:
com.ibm.jscript.InterpretException: Script interpreter error, line=6, col=37: 'db' is null
However, for production code, this is not the most elegant way to catch a bad database name. In the above scenario, the
getDatabase method assigns
null to
db and does not throw an error. The script then fails on the next line when you call
getAllDocuments on a null object.
throw
Typically you want to check the return value from
getDatabase to first determine validity. In this respect, the
throw statement is very useful. Instead of setting conditional paths good versus bad names, you can use straight-line code for a good name and throw an error for a bad name.
try {
var db:NotesDatabase = session.getDatabase(null, requestScope.dbname, false);
if (db == null) {
throw ("Cannot open database " + requestScope.dbname);
}
var dc:NotesDocumentCollection = db.getAllDocuments();
requestScope.dbcount = dc.getCount().toFixed();
} catch(e) {
requestScope.status = e.toString();
}