It is not really a problem for the Notes core code to show "all" variables that are in scope, when you compare this to the "useless" output produced by a system crash.

I implemented a borrowed idea to show a call trace when an erorr occurs. This is especially useful when you get an error in a scheduled agent or in a web application.

Absolutely Rob, web applications in particular especially when you have an illusive bug.

What do you mean by "Notes core code to show 'all' variables"? Without knowing what variables or objects there are? If only there was a way to get LotusScript to spit out a manifest of defined objects and variables then you could write it.

By the core code I mean the opposite of user written code. The compiler is aware of the scope of each variable, so it could add some extra info that can be used during a failure. It would mean too much, when the client code is keeping track of all variables, in order to achieve the same result.

I voted yes.

Mark: In the mean time, if you're willing to slow your code a little, you could keep all of your variables in a variant list.

dim lstVars List as Variant
dim db as NotesDatabase
dim session as NotesSession
set vars("db") = db
vars("strTemp") = "temporary string"
CoreDump:
forall v in lstVars
if Not isObject(v) then
Print listtag(v), cstr(v)
Else
Select Case typename(v)
Case "NOTESDATABASE"
Print listtag(v), db.title + " (" + db.Server + " " + db.FilePath + ")"
Case Else
Print listtag(v), "??? (" + typename(v) + ")"
End Select
End If

.. or something like that. If you want to tightly type all of your variables you'd have to have a different list for each type. At that point you'd probably want to create your own "VariablesContainer" class that has a CoreDump() method (that your error handling would call) and properties like
Property Get StringVar(strName as String) As String
Property Set StringVar(strName as String) As String
Sub DeleteStringVar(StrName as String)
Property Get DbVar(strName as String) As NotesDatabase
Property Set DbVar(strName as String) As NotesDatabase
Sub DeleteDbVar(StrName as String)
etc etc.

To prevent strName value typos, you could also force declaring variables to the VariablesContainer object as well by making a DeclareVar method (or set thereof, one per datatype).

I'd never thought of this until now, so my idea is admittedly half-baked. No idea how much it might or might not slow down your code. When dealing with objects, this wouldn't be too bad because you could register it and forget about it, but with non-objects you'd have to use VariableContainer every time you want to change it, which could be a nasty cost when, say, replacing a counter integer you're using while looping 1000 times. Hmmm.... maybe that could be mitigated by writing scalars to the VariableContainer within the error handling rather than using the VariableContainer every time you reference the variable?

John, thanks for eludicating your thoughts. Definitely on the right track there. After further consideration I'd like to propose a wild progression which emerges in the spirit of the rapid development paradigm. What if an errant piece of code could somehow mirror the whole machine state, then freeze (as though 'debugger is on'), and notify a developer for debugging? Developer then hooks in and steps forward/back to see what happened. Oh paradise! Take my hand.