The Growing List of Errors
Last week I got an email from somebody having problems with a particularly nasty Domino error. They had been in touch with IBM who told them they might want to have a look at this article of mine. Which leaves you wondering why they charge so much for support. To point you to the freebies?
Anyway, this got me thinking about how I need to do some work on the article Decipher domino error messages (#1 in Google btw). Which, in case you've never read it, is a long list of the errors you are likely to see as a domino developer and some suggested causes. There are a whole load of your additions that need including and a load more new ones that will always need to be added as they're discovered. Take yesterday's post for example. If we tried to access element four of a three item list in that way we would see the following error:
HTTP Web Server: Lotus Notes Exception - Array index out of bounds
How many more must Domino 6 have introduced? The article needs updating! What I'm not sure about is how to go about this. The article itself is a little lengthy and searching/updating it is a pain. What I am thinking of doing is creating a database to host each error as a document, making it easier to add and search entries.
What do you think? What's the best way to organise them? As you can see in the article, there's the error messages and any number of explanations for each. Should each explanation be a response document or simply free text in the main document? Let me know what you think you would find most useful or if I should just leave it as it is and add a few more.
Update: I've spent a few hours fiddling and created this database to record all the errors in. I've moved most over and just need to go through all the comments on the original article and consolidate them. Please add any that are missing or contribute solutions to the errors listed. To make it easier for you all to access it in the future I have setup the following shortcut:
If you create document fields for 'error message' and 'explanation', then you can offer a search on either the error or the explanation, giving a view of matches in most likely order.
You could make the whole DB open (like a wiki), or at least allow comments against each explanation so that people can chip in their own info.
What I was thinking of doing was something like this blog/response relationship. Where the responses are entered and displayed inline. I want to avoid using one field as the explanations can be manyfold and I want people to be able to add them without editor access.
Searching would then be a problem. Maybe if a search returns a solution/response document the link should open the main error document? Maybe I should just crack on with it and see how it goes?
Something like this:
{Link}
Jake, I think your approach is perfect, but it could be more easy to find the causes of a specific error if the link to the explanation was the "Full Message" field instead of the "Title" one.
Do you think title is redundant? Maybe I'll just do away with that field.
I've added a shortcut to the DB so you can bookmark/easily remember the address:
www.codestore.net/errors
The title may be redundant, to answer your question. To simply click on the error message to get the explanation would work perfectly.
Delicious!
IBM have my permission to pay YOU the support fees that they (over)charged us in the last maintenance renewal fees(given that it is now compulsory &$($ 'em!).
I visit your site daily - I have never used IBM support. Seems that they owe it to you, to do the right thing!?
Jake,
I added a new error and I think I didn't do such a good job of putting solutions separately. I was working on the java domino objects piece and I came accross notes.net document which did a good job about saying what errors mean what. I don't know you want to incorporate them into your codestore.net/errors, but here is the link.
{Link}
Thanks Veer. Not sure myself either. How should it work? You guys tell me. It's there for you as much as for me so I want it to work as you would like too...