en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en nl en en en en en en en en en en en en en en en en de en en en en en nl en en fr en en en en en en fr en da en en en en en en en nl en en en en en en en en fr en da en en en en en en en nl en en en en en en en en en en en en en sv en en en en nl en en en en en en en fr en en tr en en en en en en en en en en en nl en en en en en en en en fr en da en en en en en en en nl vi en en en en en en en en en en en en en en en en en en nl en en en en en en en en en fr en da en en en en en en en nl fr en en en en en en en en en en en en en en en en en en en en en en en en en nl en en en en pt en en en en en en fr en da en en en en de en en en fr en en en en en en en en en pt en en en en en en
By logging into your account, you agree to our Privacy Policy, personal data processing and storage practices as described therein.
Forgot password or user name?
Search in titles only Search in PowerBASIC for Windows only
You are not logged in. You can browse in the PowerBASIC Community, but you must click Login (top right) before you can post. If this is your first visit, check out the FAQ or Sign Up.
All Time Today Last Week Last Month
All Discussions only Photos only Videos only Links only Polls only Events only
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????
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? "
27 Apr 2009, 07:12 PM
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).
Port Washington WI USA
Join Date: Aug 1998
28 Apr 2009, 07:57 AM
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.
Port Washington WI USA
Join Date: Aug 2006
29 Apr 2009, 06:56 PM
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? "
Join Date: Sep 2002
29 Apr 2009, 07:56 PM
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.
My Ego Site: http://www.SwedesDock.com
PB Newby Tips: http://www.swedesdock.com/powerbasic/pb_shortcuts.html
JWAM: (Quit Smoking): http://www.SwedesDock.com/smoking
LDN - A Miracle Drug: http://www.SwedesDock.com/LDN/
Join Date: Aug 1998
30 Apr 2009, 11:55 AM
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.
Port Washington WI USA
Join Date: Aug 2006
30 Apr 2009, 05:29 PM
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 attempt 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 HILARIOUS 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? "
Join Date: Aug 1998
1 May 2009, 09:13 AM
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.
Port Washington WI USA
Join Date: Aug 2006
1 May 2009, 05:00 PM
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 every time 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? "
Join Date: Aug 1998
2 May 2009, 08:13 AM
>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.
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.
Port Washington WI USA
Copyright © 1998-2022 PowerBASIC Tools, LLC - All Rights Reserved.
Powered by vBulletin® Version 5.7.0
Copyright © 2022 vBulletin Solutions, Inc. All rights reserved.
All times are GMT-5. This page was generated at 05:38 AM.
We process personal data about users of our site, through the use of cookies and other technologies, to deliver our services, and to analyze site activity. For additional details, refer to our Privacy Policy.
By clicking "I AGREE" below, you agree to our Privacy Policy and our personal data processing and cookie practices as described therein. You also acknowledge that this forum may be hosted outside your country and you consent to the collection, storage, and processing of your data in the country where this forum is hosted.