> I first put out an alert, then add a call to a non-existent handler
Thanks for this suggestion. It's tricky, as you said. :-) From what I'm
understanding of your explanation, you're purposefully causing an error
with the goal of forcing Director to ask you whether you want to open
the debugger at that moment. Sort of like a breakpoint, without the
breakpoint.
I also pop an alert, but instead of opening the debugger at that point,
I generally return an enum value or something that helps me determine
what went wrong, and then I handle that error in the caller:
-- Caller says:
error = me.mSomeMethod( int, str )
if symbolP( error ) then
-- handle that error here
end if
on mSomeMethod( me, intFoo, strFoo )
...
if intErrNum then
alert "ERROR #mSomeMethod: File not found." && intErrNum
return #FILE_NOT_FOUND
end if
-- all is otherwise well
return FALSE
end
Consequently, some of my apps will potentially throw multiple 'levels'
of alerts for a given error, and this helps me back that error into the
proverbial corner, which is good for me at authortime.
However in my current project, I want to suppress alerts at runtime
(without just overriding them with the alertHook) but still have all the
access to what went wrong. So I'm logging it all to a table in an ODBC
data source instead, and it has renewed my desire for 'the
currentHandler' or 'the callStack'.
I'll probably put this on the D9 wishlist.
/*********************************
* Rob Wingate, Software Human *
* http://www.vingage.com *
* mailto:[EMAIL PROTECTED] *
*********************************/
[To remove yourself from this list, or to change to digest mode, go to
http://www.penworks.com/LUJ/lingo-l.cgi To post messages to the list,
email [EMAIL PROTECTED] (Problems, email [EMAIL PROTECTED])
Lingo-L is for learning and helping with programming Lingo. Thanks!]
