Error Handling - Ideas for "Beefed-Up" Functions

[Cliff Nichols]

I have an idea (or 2 or more) of an inc file to "Beef-Up" normal Error Handling Techniques (some redundant, some a bit more detailed) that seem to be coming along fine, but hopefully some people can help me shortcut some research (or explain some stuck points I hit in my understanding of documentation)

Right now, this is kinda generic until I can post code to demonstrate, but some questions that come to mind are:

ERL: Return the last line number encountered before the most recent error.

• Since ERL is a PB KeyWord, is there an API equivelent?
• Does ERL only work if in the core *.bas file??? (My initial Tests tell me this is the case, cause in my *.Inc, it always shows line 0 or 1 (depending on how I write the code) meaning either error at the time of passing, or I need to do a bit more beefing because ERL changes once I pass on to another function?

ERROR <Insert Number>

• Can not be raised within callback, because I escape the callback, and any messages not handled are "Lost"??? (or I think this is the case???)
• SetLastError = the API equiv of ERROR (but I still must raise the error to fire the event?)

Next is a bit Harder, but my ideas of errors that could occur in DLL's or INC files that I did not write were to log a copy of Function and parameters passed (Just like TRACE, but a lil bit deeper). My First try was with anything out of my control was to have a string variable that before I call I place a string copy of what is about to be called (since unknown number of parameters, and unknown function to be called)...then I started seeing a pattern....and then another discussion mentioned "DISPPARAMS"

• Is "DISPPARAMS" only used with objects (like OCX???)
• How is it used?? (Simple example would help) since examples I have seen are confusing at the moment
• Is there a better procedural way??? (Been figuring that one out myself, but maybe that wheel has already been invented???)

Anyways, enough of confusing questions, but hopefully some people out there have some constructive ideas???

[José Roca]

DISPPARAMS has nothing to do with error handling. This structure is used exclusively by the Invoke method of the IDispatch interface and contains the arguments passed to a method or property.

Usage example: http://www.powerbasic.com/support/pb...ght=dispparams

[Michael Mattias]

Since ERL is a PB KeyWord, is there an API equivelent?

The "error line" is source-code dependent... Windows don't know nuthin' bout the source code. So: No.

Does ERL only work if in the core *.bas file???

I'd guess YES because PB does not use a shared runtime module. (eg VBRUN600.DLL). All pb-compiled DLLS and EXEs are totally independent of each other: what happens in "Las Vegas.DLL" stays in "Las Vegas.DLL"

SetLastError = the API equiv of ERROR (but I still must raise the error to fire the event?)

SetLastError is only superficially the equivalent of PB ERROR: it sets the value that GetLastError() will return on that thread if called immediately thereafter, but since Windows does not have the equivalent of "ON ERROR..." it does nothing else.

SetLastError() is used to preload the GetLastError() when you want to test for specific values. I've only used it once or twice, a couple of years ago, for some obscure API call I don't think I've used since.

You could, however, set up a 'wait thread' on a user defined event, and signal that event if you want something you can react to from anywhere in your program.

eg... Terminate Worker Threads Using Windows Events (and Using Thread Local Storage) Demo Dec 23 2005

This uses a "named event" for the cancel. You can get a handle to that event from any module of the current process... or for that matter, from any other process, too.

MCM

[Cliff Nichols]

Thank you Jose...(since my gut instinct and confusion kinda told me what you confirm without me wasting tons of time researching just to find out that 1st clue was right)

MCM Thank you for confirming things that I have always held true myself..but over the years wondered if something had changed.

Since ERL is a PB KeyWord, is there an API equivelent?
The "error line" is source-code dependent... Windows don't know nuthin' bout the source code. So: No.

Thats what I thought but had to ask

Does ERL only work if in the core *.bas file???
I'd guess YES because PB does not use a shared runtime module. (eg VBRUN600.DLL). All pb-compiled DLLS and EXEs are totally independent of each other: what happens in "Las Vegas.DLL" stays in "Las Vegas.DLL"

Yep...thats what I guessed too, but I unfortunately have VB influence so I had to ask if that influence was just because "What I was used to??, or How things really work???"

SetLastError = the API equiv of ERROR (but I still must raise the error to fire the event?)
SetLastError is only superficially the equivalent of PB ERROR: it sets the value that GetLastError() will return on that thread if called immediately thereafter, but since Windows does not have the equivalent of "ON ERROR..." it does nothing else.

SetLastError() is used to preload the GetLastError() when you want to test for specific values. I've only used it once or twice, a couple of years ago, for some obscure API call I don't think I've used since.

Which kinda leads to the whole debate of compiler vs code concept, and the idea that it may be possible to trick both with "ON 32 Goto" kinda thing
(that is a debate of a whole other world, so I won't bring it up again )

You could, however, set up a 'wait thread' on a user defined event, and signal that event if you want something you can react to from anywhere in your program.

I stopped with partial quote, because I am leaving threads out of it for the time being (or at least to my knowledge...not to say I am not threading and dont know it)

Baby steps...one at a time

That said...are you eluding that I am taking steps that I am not aware of???

and I have a partially <Code SHOWN. but not sure if it belongs in Source Code?? or if it belongs in the "Test Forums" because I still question things that are partially hardend Cement"
:laugh:

[Kev Peel]

ERL needs a actual line number label specified. The number returned does not refer to a line index in your file. See with the following example, the error trigger with the line number specifier will work, the other not

#Compile Exe
#Dim All
 
Function PBMain
  On Error GoTo report:
 
  10 Error 5 ' Correct ERL usage.
  'Error 5    ' Incorrect.
  Exit Function
 
  report:
  ? Error$ + " on line " + Format$(Erl), , "Error"
End Function

[Michael Mattias]

I take it back, kind of

Structured Exception Handling can be coded into your program.

Start with the SetUnhandledExceptionFilter() function in your WinAPI reference.

Seems to me I did a demo of this, but I don't see it in my list. IIRC, I could trap the exceptions but basically found myself 'in jail' and unable to do anything but report the error... ie, no way to "resume" anywhere.

Maybe if I run out of things to do I'll try again, since I am positive I first tried it when I had the Win/98 box. Maybe I could get something which would work better on Win/XP.