Announcement

Collapse
No announcement yet.

RaiseException Again

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • RaiseException Again

    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???
    Code:
    '#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????
    Engineer's Motto: If it aint broke take it apart and fix it

    "If at 1st you don't succeed... call it version 1.0"

    "Half of Programming is coding"....."The other 90% is DEBUGGING"

    "Document my code????" .... "WHYYY??? do you think they call it CODE? "

  • #2
    > 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
    Tal Systems (retired)
    Port Washington WI USA
    [email protected]
    http://www.talsystems.com

    Comment


    • #3
      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
      Michael Mattias
      Tal Systems (retired)
      Port Washington WI USA
      [email protected]
      http://www.talsystems.com

      Comment


      • #4
        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
        Engineer's Motto: If it aint broke take it apart and fix it

        "If at 1st you don't succeed... call it version 1.0"

        "Half of Programming is coding"....."The other 90% is DEBUGGING"

        "Document my code????" .... "WHYYY??? do you think they call it CODE? "

        Comment


        • #5
          Originally posted by Cliff Nichols View Post
          .. 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
          ======================================================
          It's a pretty day. I hope you enjoy it.

          Gösta

          JWAM: (Quit Smoking): http://www.SwedesDock.com/smoking
          LDN - A Miracle Drug: http://www.SwedesDock.com/LDN/

          Comment


          • #6
            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
            Michael Mattias
            Tal Systems (retired)
            Port Washington WI USA
            [email protected]
            http://www.talsystems.com

            Comment


            • #7
              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
              Engineer's Motto: If it aint broke take it apart and fix it

              "If at 1st you don't succeed... call it version 1.0"

              "Half of Programming is coding"....."The other 90% is DEBUGGING"

              "Document my code????" .... "WHYYY??? do you think they call it CODE? "

              Comment


              • #8
                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
                Michael Mattias
                Tal Systems (retired)
                Port Washington WI USA
                [email protected]
                http://www.talsystems.com

                Comment


                • #9
                  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 :coffee4: , test, re-read :coffee2:, test, re-re-read :coffee: , test again, and re-re-re-read :coffee3:
                  (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.
                  Engineer's Motto: If it aint broke take it apart and fix it

                  "If at 1st you don't succeed... call it version 1.0"

                  "Half of Programming is coding"....."The other 90% is DEBUGGING"

                  "Document my code????" .... "WHYYY??? do you think they call it CODE? "

                  Comment


                  • #10
                    >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....
                    Code:
                    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.
                    Michael Mattias
                    Tal Systems (retired)
                    Port Washington WI USA
                    [email protected]
                    http://www.talsystems.com

                    Comment

                    Working...
                    X