Page 1 of 1
Limits of OnErrorCall
Posted: Wed Jul 16, 2025 5:15 pm
by sc4pb
I have an application that crashes, as in completely disappears with no errors, no warning, even though I have OnErrorCall() in place. I was hoping OnErrorCall allowed for unexpected errors to be trapped in a handler so I could do a graceful exit and log the event.
The application creates a PDF report. I had an accidental situation where a bad filename could be supplied to PdfVectorOutput(), causing StartVectorDrawing() to then fail. After that a call to VectorFont() causes the entire program to crash with no warning. (Yes, yes, I was checking result of StartVectorDrawing, and it was a mistake on my part that the program was continuing to render the report.)
But a bad filename, or hard drive full, or a networking error, these are all good examples of situations that could arise unexpectedly, and I assumed that as a worst case an error handler would allow the event to be logged, so that the root cause could be fixed.
So... why does the following OnErrorCall example not work, and what exactly are the limits to what type of errors can be trapped?
(I compiled below to an .exe on Windows 10, PB 6.12 with "Enable Debugger"
unchecked in compiler options.)
Code: Select all
Procedure VectorErrorOnPurpose()
LoadFont(0,"Times New Roman",20)
VectorFont(FontID(0),18)
EndProcedure
Procedure ErrorHandler()
MessageRequester("test","Error trapped successfully!")
EndProcedure
MessageRequester("test","Enable Error trapping")
OnErrorCall(@ErrorHandler())
MessageRequester("test","Causing error...")
VectorErrorOnPurpose()
MessageRequester("test","Should never see this!")
Thanks
Re: Limits of OnErrorCall
Posted: Wed Jul 16, 2025 7:14 pm
by mk-soft
Programming errors are not intercepted.
Here you must always also evaluate the return from the PB functions themselves.
The following errors are started by OnErrorCall. See function ErrorCode()
Code: Select all
#PB_OnError_InvalidMemory : Read or write operation on an invalid location
#PB_OnError_Floatingpoint : Floating-point error
#PB_OnError_Breakpoint : Debugger breakpoint reached (non-PureBasic breakpoints)
#PB_OnError_IllegalInstruction : Attempt to execute an illegal instruction
#PB_OnError_PriviledgedInstruction: Attempt to execute a privileged (system-) instruction
#PB_OnError_DivideByZero : Division by zero (Windows only)
Valid procedure:
Code: Select all
filename.s = SaveFileRequester("PDF", "", "", 0)
If filename
vector_output = PdfVectorOutput(filename, 800, 1200, #PB_Unit_Pixel)
If vector_output
If StartVectorDrawing(vector_output)
; todo
StopVectorDrawing()
Else
Debug "Error: StartVectorDrawing"
EndIf
Else
Debug "Error: PdfVectorOutput to file " + filename
EndIf
Else
Debug "Cancel."
EndIf
Re: Limits of OnErrorCall
Posted: Wed Jul 16, 2025 10:01 pm
by BarryG
Always check the return value of commands that give one. Always. For example, a bad filename error should never occur, because you used the CheckFilename() command with it first. Things like that.
Re: Limits of OnErrorCall
Posted: Thu Jul 17, 2025 1:05 am
by Piero
BarryG wrote: Wed Jul 16, 2025 10:01 pmCheckFilename()
Code: Select all
Procedure.s QuoteString(str$) ; useful to quote FILE/FOLDER PATHS (Mac/Linux Shell)
ProcedureReturn "'" + ReplaceString(str$, "'", "'\''") + "'"
EndProcedure
Re: Limits of OnErrorCall
Posted: Thu Jul 17, 2025 2:42 pm
by sc4pb
Okay let me ask another way...
The OnError system is apparently not what I'm looking for, now that I understand its scope.
There is also the debugging system. In the event of a programming error (a bug! yes, we all let one escape into the wild now and then), If I compile a program with debugging enabled, and deploy it to a customer, is there a way to, in the event of a bug like the one I described, to toss execution to a handler routine before exiting?
Execution speed is not a concern. I don't want the full PB debugger in the field. But clearly the debugging system is capable of identifying errors of this kind because that's exactly what it does when you run from the IDE. Maybe this is a wishlist item: I'd like a way, through debugger library or whatever, that when a compiled and deployed program runs into an unexpected programming mistake, instead of just folding up and crashing, toss execution to a handler, so that a message like "an unexpected error has occurred, please contact..." could be displayed.
Thanks.
Re: Limits of OnErrorCall
Posted: Thu Jul 17, 2025 6:44 pm
by Little John
<deleted>
Re: Limits of OnErrorCall
Posted: Thu Jul 17, 2025 6:49 pm
by Fred
if you compile in console mode, you can enable the debugger and ship it with it, but it shouldn't be put in production IMHO as it contains info about the source file name, etc.
Re: Limits of OnErrorCall
Posted: Fri Jul 18, 2025 9:44 am
by PBJim
Fred wrote: Thu Jul 17, 2025 6:49 pm
if you compile in console mode, you can enable the debugger and ship it with it, but it shouldn't be put in production IMHO as it contains info about the source file name, etc.
I have some sympathy for the requirement — the PB debugger serves a very good role for highlighting certain errors that we might not necessarily identify otherwise, especially memory handling errors. In this sense the console debugger could be a possible option with a collaborating end-user, when working together to try to resolve an illusive and difficult bug.
I don't see the need to add a feature though, as the post perhaps suggests — it's part of the need for adequate testing before releasing and we can do the above already.