RaiseException Again

[Cliff Nichols]

I am trying to get my head wrapped around error handling again, and more explicitly the RaiseException Api call.
(Unless I am missing a Raise Error type call like back in VB)

what I am having trouble with is when I raise an exception, no matter what exception flags I use, my computer comes back with the typical has to close box.

and for the most part all examples I have found do the same, and I am totally lost at the docs as in what I thought passing a flag of continue execution is being ignored??

Below is some test code I am working on, but not sure where I am going wrong???

'#DEBUG ERROR ON
#COMPILE EXE
#DIM ALL
#INCLUDE "Win32Api.inc"
FUNCTION PBMAIN () AS LONG
     ON ERROR GOTO ErrHandler                          'If error rasied then jumps to error handler
     LOCAL ForceCodeContinue AS LONG
     ForceCodeContinue = %TRUE
     ERROR 5                                           'Set Error Code (Error is raised, jump to error handler)
     MSGBOX "Continued from raised error"              'Results
     ERR = 5                                           'Set Error Code (Error is not raised)
     MSGBOX "Continued again, but no error raised"     'Results
     ForceCodeContinue = %FALSE
'*** Use 'SetLastError' if flags are not used, but use 'SetLastErrorEx' if wanting extra info
     SetLastErrorEx(5, %SLE_MINORERROR)                        'Invalid data was passed to the function, but the function has recovered.
     RaiseException 5, BYVAL %SLE_MINORERROR, BYVAL %NULL, BYVAL %NULL         'Bogus Fatal Error for Demo (or not fatal since I have control)
     MSGBOX "Error (Minor, code continues)"
     SetLastErrorEx(5, %SLE_WARNING)                        'Potentially invalid data was passed to the function, but the function has recovered.
     MSGBOX "Error (Warning, code continues)"
     SetLastErrorEx(5, 0)                        'The last-error code is set without reporting anything to the debugger. Specifying this value is equivalent to using the SetLastError function.
     MSGBOX "Error (Nothing reported to debugger)"
'*** This last one must be last or your tests will result in the typical error of "*.Exe Has Stopped Working" no matter what the error number is
     SetLastErrorEx(5, %SLE_ERROR)                        'Invalid data was passed to the function, and complete failure has occurred.
     RaiseException 42, %NULL, %NULL, %NULL         'Bogus Fatal Error for Demo (or not fatal since I have control)
     MSGBOX "Error (Major, and can not continue)"

     EXIT FUNCTION                                     'Exit to not execute error handler
ErrHandler:
     MSGBOX "Error was raised"                         'Error raised
     SELECT CASE ErrorHandling(ERR, ForceCodeContinue)
          CASE %FALSE
          CASE %TRUE
               RESUME NEXT
     END SELECT
END FUNCTION

FUNCTION ErrorHandling(ErrorNumber AS LONG, ForceCodeContinue AS LONG) AS LONG
     MSGBOX "Error Handled"
     SELECT CASE ForceCodeContinue
          CASE %FALSE
               FUNCTION = %FALSE
          CASE %TRUE
               FUNCTION = %TRUE
          CASE ELSE
               FUNCTION = %TRUE
     END SELECT
END FUNCTION

Even passing any error number and a flag of %SLE_MINORERROR (which should allow continuance) causes the same symptoms.

Does anyone have some code that better explains how the docs explain (cryptically) should actually behave without the zeros for parameters????

[Michael Mattias]

> RaiseException 5

Of course you got the standard close box for code 5 (attempt to access unowned memory) - you have no exception handler coded, so the default handler was used!

If the process is not being debugged, or if the associated debugger does not handle the exception, the system provides default handling based on the exception type. For most exceptions, the default action is to call the ExitProcess function.

(HINT: see SetUnhandledExceptionFilter() function. Also, search here for that. I know I posted something a long time ago using it).

MCM

[Michael Mattias]

FWIW, I am genuinely impressed with your willingness and initiative to just, "try it."

If you find my post on this... as I recall, I was able to catch these exceptions, but I gave up refining the code because that's all I could do.... report that said exception had occurred... which I already knew from the default handler ("programname must close...")

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

MCM

[Cliff Nichols]

Of course you got the standard close box for code 5 (attempt to access unowned memory) - you have no exception handler coded, so the default handler was used!

Mistake #1 (but well worth the while since my original attempt was to over-ride the window to begin with)


using Juergen Vierheilig Catch Fatal Errors.bas I am coming close (although I can not make it work with a dll yet, but) coming close


Fun part is that it IS possible to recover from a "Fatal" error, and continue running. (Kinda contradictory cause why would you want to continue if you hit a error?) *LOL*

Hope to post soon what I have learned, and correct previous posts I made in the past

[Gösta H. Lovgren-2]

.. and correct previous posts I made in the past

Hmmm... that could turn out to be quite a project, depending on how far back you want to go. {grin}.

======================================================
Lazy people are always anxious to be doing something.
Luc, Marquis de Vauvenargues
======================================================

[Michael Mattias]

Fun part is that it IS possible to recover from a "Fatal" error, and continue running. (Kinda contradictory cause why would you want to continue if you hit a error?) *LOL*

I agree trying to do anthing intelligent following a code 5 (unowned memory) exception makes little sense... but.....

You could be trying to cover for the PB compilers' lack of a #DEBUG OVERLFOW ON directive by catching numeric overflow/Underflow exceptions ... then "knowing" that whatever was in the original input operands resulted in same, you could report that 'result' as 'error', and continue processing the rest of the input.

MCM

[Cliff Nichols]

You could be trying to cover for the PB compilers' lack of a #DEBUG OVERLFOW ON directive by catching numeric overflow/Underflow exceptions ... then "knowing" that whatever was in the original input operands resulted in same, you could report that 'result' as 'error', and continue processing the rest of the input.

Actually my original intent was to correct or ignore errors that I intentionally raised. (Stuff like opening a port, just to see if it was already open and such) just because I had no way of checking otherwise (or at least with the knowledge I have)

Overflow and Underflow???? (Never could get the concept of things like that) but if someone could plain english explain the basic principle maybe the way it is phrased I could catch on and realize in my own terms of what it means.

I have to admit, this attemp is showing me a ton of things I do not understand yet, and it is really funny that one attempt would crash the test, but commenting out 1 line would make it work. (But the HILLARIOUS part of commenting, would give me a messagebox with some character (I expected as such) but the "OK" button showed up like something from "Captcha" and print the word "OK" ****-eyed and bent)

All in all pretty interesting but definitely FRUSTRATING (especially in circumstances that I can not use debugger to walk through step by step what is happening)

It seems like I am climbing a tower of babel, and hoping to not fall down to awake speaking ancient latin

[Michael Mattias]

Overflow = divide by zero (which will currently result in protection fault). Also occurs when adding/multiplying two numbers which exceed capacity of registers, but I think the compiler already picks those off and returns "junk" but no protection fault or error.

Underflow = divide by number resulting in quotient too small to represent with chosen numeric type (which may currently return zero without exception, caught by runtime library).

You can also get these with some LOG() and possibly with some trig functions, depending on how implemented; but again I think the compiler may already be picking some of these off.

Divide by zero (or number small enough to be "effectively zero" in context ) is my big concern.


MCM

[Cliff Nichols]

Overflow = divide by zero
Underflow = divide by number resulting in quotient too small to represent with chosen numeric type

Thank you MCM, short and to the point. So now in my mind

Overflow = divide by zero
Underflow = results so close to zero that it can not be shown using my datatype

Is there another case of underflow/overflow? besides with numbers?
Reason I ask, is I have wasted a day chasing my tail trying to read , test, re-read :coffee2:, test, re-re-read :coffee: , test again, and re-re-re-read
(and not done yet)

Thank god for the Win32Api.inc file (<--- at least that gives me "This points to that which in turn points to another in which may point to another, and then match that to the doc, and wonder "WHY THE HECK DID M$ NOT JUST SAY SOOOOoooo instead of being so cryptic????")
(Dagnabit C programmmers <--- Insert explative)

Well the journey is a learning one, and shows me why no one has really dug deep. (Royal Pain in the) and stopped at a point which satisfied their needs.
(Or at least I have not found any in the forums just yet)

Anyways, just an update, that it will take longer than I 1st expected (probably longer to comment) but everytime I think of giving up, the burr under my saddle will NOT let this ole dog let go of that old bone.

[Michael Mattias]

>Underflow = results so close to zero that it can not be shown using my datatype

That is not correct. The protection exception occurs when the registers used for the calculation cannot hold the value... at runtime. "Your datatype" is a compile-time concept and would have to be trapped by the compiler or its runtime library.

Eg....

LOCAL B AS BYTE
   DO WHILE B  < 256 
        B = B + 1
   LOOP

I think that loop will run forever, the 'datatype overflow' on "B + 1" when B=255 being ignored.
But you don't get a protection fault on this, so there's nothing you can do about this other than "don't do that" and asking the compiler vendor to implement overflow checking.