Raising Errors for Testing

[Cliff Nichols]

I get that PB can catch its own internal errors via DDT with the ON ERROR and set the Error number, but does SDK have an equivalent? (I know I can check GetLastError after every SDK call, but was looking to see if I could somehow ON SdkERROR goto sort of thing)

I am working on a error handler to at least log (if not correct) errors that I may have, and can not find, or did not think of.

SDK also has RaiseException and the ability to add your own exception handler, but to my knowledge (still reading the docs) that would be more for GPF's or some unavoidable crash (like corrupting memory)

Since its a learning concept and mixing SDK and DDT (in some cases one should NOT do) I am looking at somehow doing a ON ERROR goto concept via my SetLastError, but my only guess is to SETLASTERROR, and then GETLASTERROR and then pass to a function to see if there was an error?

I would hate to have to check GetLastError after every SDK call, but if that is the only way, then I can live with that.

[Michael Mattias]

Other than structured exception handing ("pending GPF") , no.

However, at least 97% [that's a visceral, not an empirical figure] of WinApi calls return a success/fail code which can be tested in your code ; and on failure you can call GetLastError for at least 90% of those.

Note also that the compiler itself generates a lot of calls to the WinApi... calls you never see.. and on those errors the compiler itself translates those success/fail codes into PB errors for you.

E.g.

   REDIM X(too many to fit in memory).

When the memory allocation requested by the compiler for this statement fails, the compiler calls getlasterror and translates the return code to "ERROR 7 Insufficient Memory" for you.

[Michael Mattias]

Of course, when an API call fails you can always use the ERROR statement to generate a PB Error and kick in any active PB error handler.

There is a range of errors set aside for the user (that would be YOU). Use one of those and you can have an error handler like...

%USER_DEFINED_API_ERROR_VALUE = Any unused value 1-255 see help for used numbers 

.......

  ON ERROR GOTO ErrorHandler

  Z  =      APIFunction (param) 
  IF ISFALSE Z   THEN    ' failure 
        ERROR %USER_DEFINED_API_ERROR_VALUE
  ELSE...
     ......

ErrorHandler: 
   IF ERR =  %USER_DEFINED_API_VALUE  THEN
        Call GetLastError  to get the system failure code 
        Call FormatMessage to get the text for that error 
   ELSE 
       it must be a PB ERROR, call ERROR$(ERR) to get the text 
  ...
  RESUME somewhere

.....

[Conrad Hoffman]

It's easy enough to work around, but why do the user defined errors have to be 151 through 240 only? It would be really nice to go above 255.

[Michael Mattias]

>151 through 240 only? It would be really nice to go above 255.

What, you are editing for more than 92 separate errors requiring ON ERROR handling?

Show code.

[Conrad Hoffman]

I send a lot of identical commands to a piece of test equipment, and it's convienent to throw different error messages depending not only on what I sent, but where in the sequence it failed. No doubt an extreme example and maybe using ERROR isn't the best way, but it was handy and worked well.

[Cliff Nichols]

Posted in Source Code

After working on it so long, and finding repetition in error handling in extreme cases, I think I am finally on the right track.

For the most part all my other attempts have been "application specific" as MCM would put it. Which is true because each application has its mix of DDT and SDK (no matter how much you try, but there is some smattering of one or the other)

So I jumped the shark, and took a bit from Jose, a bit from others, and dare I say even a few ideas from MCM (never saw the use in Macro's till now)
and posted the beginnings of what I hope to become the ultimate runtime-debugger that I have above and beyond all other precautions I have in place to prevent me using it.

Smaller projects...yep it may take a bit, but we finally find the CNDS (as MCM coined it "Cliff Nichols Doh Syndrome") but the larger the project, the harder it gets.

PB warns against keeping tools on and debugging to keep your distributed file size down... (and I agree, but)

call me a pirate but PB has kept the sizes down so much, I think I can afford a lousy 33Kb file to save me days (if not weeks) of headaches years down the line trying to debug something I write today "Full Steam Ahead Mr. Washington"

So I submitted what I have running for a RunTime Debugger (more a logger than anything) that you can toggle on and off as needed to troubleshoot those "Elusive Unicorns" that crop up as bugs in your code.
RunTime Debug - and Error Handling Part I

Let me know what you guys think...I am already spurning gears on what I can do to beef things up (once I understand them that is )

[Michael Mattias]

MIght I suggest that with that many different errors to capture and report, ON ERROR GOTO might not be the most effective coding style.

You can still handle errors without ON ERROR GOTO ....

    Z =  SomeUserFunctionCall (some params) 
    IF Z <> %SUCCESS  THEN 
       CALL GetMyErrorMessageText (Z) to StringVar 
    ....

????

[Cliff Nichols]

One thing I just noticed adding the ErrorHandler into my much larger project, is that I have subroutines in the project (So the compiler would raise errors for the "Exit FUNCTION" because its not a function)

Is there a way to determine if a Sub or Function at runtime?

If not, then I will just change all my Subs to Functions and not care that there is nothing to be returned.
(I just thought if I was going to make an ErrorHandler, why not make it RIGHT)

[Michael Mattias]

>Is there a way to determine if a Sub or Function at runtime?

No.

But the program won't compile if you try to 'EXIT FUNCTION' from a 'SUB,' so there won't be a runtime anyway.

>If not, then I will just change all my Subs to Functions

That will work. I have not written a SUB in six years.


MCM

[Cliff Nichols]

I always thought the same, and now realize a small drawback as to what as SUB would be (Just do what I say), vs a FUNCTION (Just do what I say, but tell me about it, but if I don't care what you have to say, I just don't let you report back, or I dont look to see what you had to say)

Anyways, so far so good,(although it took me over 8 hours to replace all my previous debugging handlers with this one, but that is a a matter of how huge the code source is)
I still have to go back and compare file sizes, but I think the minor increase will diminish due to functionality

Sad part is although initial test work great as long as part of a EXE, I fail miserably if as part of a DLL (but I am sure its got to be part of my coding, or breaking some rule that I am not aware of)

Well back to the drawing board, (and thankfully Vacay time is coming soon )