Limits of OnErrorCall

[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

[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

[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.

[Piero]

CheckFilename()

Code: Select all

Procedure.s QuoteString(str$) ; useful to quote FILE/FOLDER PATHS (Mac/Linux Shell)
   ProcedureReturn "'" + ReplaceString(str$, "'", "'\''") + "'"
EndProcedure

[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.

[Little John]

<deleted>

[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.

[PBJim]

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.