Raise Errors On Purpose (SDK)

[Cliff Nichols]

I am close to posting an error handler for run-time, but I still have a minor problem.

I know I can "Raise" an error in PB for testing purposes using "ERROR"
I also know that just setting "ERR = some number" does not actually "RAISE" and error, it just sets an error value.

The SDK equivalent Are SetLastError and SetLastErrorEx. But they too only set the error flag.

"RaiseException" will raise the almighty "Had a problem and has to close" box.

How the heck do I raise and error, that I am just testing? in SDK?

I need to raise an error like PB Error 69 which says the file does not exist, but it does not end the program. Nor should it, it is just telling me the file is not there.

How do I raise an error in SDK that is not a FATAL error????

[Michael Mattias]

You are doing it right; RaiseException() is the WinAPI version of ERROR 'n'.

But you need to make sure you have an exception filter in place to 'do something' when you raise that exception. (SetUnhandledExceptionFilter()).

When you code ON ERROR GOTO, or TRY...CATCH, that's the PB version of "SetUnhandledExceptionFilter" except it's a lot easier to use than RaiseException.

Remember, many of your calls to WinAPI functions already handle exceptions themselves.. they communicate failure back to you via the return code of the function. Not all, but many.

[Cliff Nichols]

Thanks MCM,
You kinda verified what I was already thinking. (Someone or Something, has already handled it for me. But I can not see it)

RaiseException, I kinda figured was the only equivalent of Raising an error, but every example I find is a "TRY/CATCH/FINALLY" sort of thing. (Structured Error Handling)

And Here I am working on "How the heck did THAT error get past me????" and "Where the heck is it???" idea

The fun part is, if you are correct, then I finally know how to RAISE an error, and recover from it without crashing the app.

I am working on getting a posting to the Source Code Forum, but you will be happy to know from our discussion at RaiseException Again you made the comment of

I never was able to figure out how to 'recover' ... that is, report the error and then resume execution somewhere.

Well I FINALLLY cracked the code there, and hopefully it will make sense when I post it.

For now I am on the idea of RaiseException = Raise Error. If I am wrong, please someone let me know

[Kev Peel]

The Windows' exception handler is for 'fatal' errors only (ie. ! INT 3 will generate a breakpoint exception).
Non-fatal errors can be handled via return codes and GetLastError.

[Cliff Nichols]

Kev marks the spot that I am trying to find.

I have an error, so I set it, but the only way anyone sees it is if they check the "GetLastError"

Exceptions are the only way I know of at the moment to start waving my arms and say "HEYYYYYY I got a problem here...you may want to look before deciding to continue"

Again...Setting an Error Flag <> Raising an Error Flag

[Michael Mattias]

Mr. Peel's point is a good one: Windows already handles most exceptions for you via return codes and the GetLastError() value.

A lot depends here on exactly what you are trying to simulate and/or recover from.

If you are trying to track a non-null but nonetheless invalid pointer, a 0x'0005' exception handler is what you need. (Null pointers are handled by the compiler if you use #DEBUG ERROR ON).

Numeric overflow/underflow is another place where the compiler offers no tools, so you will have to handle those exceptions yourself, too.

But other than these I am hard-pressed to think of any exceptions you would want to handle via the Windows' exception facilities.

MCM