Optional step out index for DebuggerError() and DebuggerWarning() to highlight the calling line

[STARGÅTE]

Code: Select all

DebuggerError(Message$ [, StepsOut])
DebuggerWarning(Message$ [, StepsOut])

Currently, we have DebuggerWarning() and DebuggerError() to generate a runtime debugger error at this specific line.
However, when I create a Module (or an include file) using this functions to send a warning or error message because of an runtime issue in a module's procedure, I would like to automatically step out one (or more) calling steps to highlight the error at the position where the module procedure is called, not where DebuggerWarning is called.

Current work-around: viewtopic.php?p=651468#p651468 posted by freak

• Current behavior: Highlighted line inside the procedure, always on line 3.
  Not helpful for the person working with this procedure.

  Code: Select all

  Procedure SomeProcedure(Param1.i)
  	If Param1 <= 0
  		DebuggerWarning("Param1 should be positive, but it was "+Param1)  ; Highlighted
  	EndIf
  EndProcedure
  
  SomeProcedure(1)
  SomeProcedure(0)
  SomeProcedure(99)
  SomeProcedure(-100)
  

  [21:30:35] Executable started.
  [21:30:35] [WARNING] testi.pb (Line: 3)
  [21:30:35] [WARNING] Param1 should be positive, but it was 0
  [21:30:35] [WARNING] testi.pb (Line: 3)
  [21:30:35] [WARNING] Param1 should be positive, but it was -100
  [21:30:35] The Program execution has finished.

• Wished behavior: Highlighted line at call position, i.e. line 8 and line 10.
  The person working with this procedure knows exactly at which call the issue occurred.

  Code: Select all

  Procedure SomeProcedure(Param1.i)
  	If Param1 <= 0
  		DebuggerWarning("Param1 should be positive, but it was "+Param1, 1) ; Optional parameter lead to a step out.
  	EndIf
  EndProcedure
  
  SomeProcedure(1)
  SomeProcedure(0)  ; Highlighted
  SomeProcedure(99)
  SomeProcedure(-100)  ; Highlighted
  

  [21:30:35] Executable started.
  [21:30:35] [WARNING] testi.pb (Line: 8)
  [21:30:35] [WARNING] Param1 should be positive, but it was 0
  [21:30:35] [WARNING] testi.pb (Line: 10)
  [21:30:35] [WARNING] Param1 should be positive, but it was -100
  [21:30:35] The Program execution has finished.

[#NULL]

+1
would be handy for libraries, especially since we can't implement something like it ourselves. In some simple cases you can use macro wrappers for your public procedures, which either throw an error or call the procedure, but it's not a general solution.

[freak]

The problem especially with DebuggerError() is that it will stop execution while inside the DebuggerError() command, so if you continue/step after the error, it will also continue on the next line after this command. Highlighting a different line than the one with the command would be very confusing in this case. The marked line would jump around in a weird way.

[STARGÅTE]

The problem especially with DebuggerError() is that it will stop execution while inside the DebuggerError() command, so if you continue/step after the error, it will also continue on the next line after this command. Highlighting a different line than the one with the command would be very confusing in this case. The marked line would jump around in a weird way.

That's why DebuggerError(Message, 1) could "simply" perform a step-out before triggering the stop-execution error.
For DebuggerWarning() there is no such a problem, as the code continues anyway.

[freak]

What if there are other errors along the way? Do we ignore those, or do we ignore the original one? Or do we claim they both happened at the outer location? Or do we stop at the innermost error and just remember somewhere that at some point in the future we have to stop and show another error? What if there is an endless loop and we never reach the outer location? Do we just ignore the error and keep going indefinitely? This gets messy very fast.

[spikey]

Isn't this what the Callstack is for in any case?

[STARGÅTE]

Thank you so much for thinking about this request.
I would like to use DebuggerWarning() and DebuggerError() more often in modules, but in their current implementation they help the programmer of the module, but not the user of the module who doesn't want to know anything about the module's code itself.

What if there are other errors along the way? Do we ignore those, or do we ignore the original one? Or do we claim they both happened at the outer location?

In the simple case of DebuggerWarning(), if both triggered errors are called with the additional parameter for stepping out, they both sent and marked at the outer location.
This would be similar to "LoadImage(1, "foo.bar") : LoadImage(2, "bar.foo")", where the log file reports two times "[WARNING] Line: 1 The specified file does not exist."
In case of DebuggerError(), the additional step-out index should immediately leave the procedure by a return, because the procedure obviously failed. So additional errors (inside the procedure) are ignored and infinite loops are avoided.
This would be similar to "CreateImage(-1, -4, -4)". Here, only "[ERROR] CreateImage(): Image 'Width' is too small, should be > 0." is shown, and by continuing the code the next fatal error "Image 'Height' is too small" is not shown.

What if there is an endless loop and we never reach the outer location? Do we just ignore the error and keep going indefinitely?

Well, this would be in the hands of the programmer, dealing with Warning or Error.
A DebuggerWarning() with step out index 1, wouldn't show up in an infinite loop.
A DebuggerError() with step out index 1, would leave the procedure by a return and would show up an error.

[freak]

What you may want to do is wrap your code in a DisableDebugger block. This way the debugger will not know the lines inside the code block and triggering a warning/error will appear as though it happened on the last line before entering the disabled section (usually this is the caller of the procedure then). This will do what you want.

The only problem is that DisableDebugger will also render DebuggerError() inactive as well. You can work around this by using the function that is available for debugger checks in libraries. This one will not be ignored by DisableDebugger.

Note that this solution also disables any PB runtime checks in your code and the user cannot step into it. But if you want to treat the code as if it were a library, this should be fine, too.

Code: Select all

; From DebuggerModule.h in the SDK folder
; Unlike The DebuggerError() command, these are not ignored inside a DisableDebugger section.
; Using them will make it appear as though the line that caused the error/warning is the one executed before entering the DisableDebugger section (so usually the function caller)
CompilerIf #PB_Compiler_Debugger
  Import ""
    PB_DEBUGGER_SendError(Message.p-ascii)
    PB_DEBUGGER_SendWarning(Message.p-ascii)
  EndImport  
CompilerElse
  ; Dummies for non-debug compile
  Macro PB_DEBUGGER_SendError(Message): EndMacro
  Macro PB_DEBUGGER_SendWarning(Message): EndMacro
CompilerEndIf


; Treat this procedure like a library. I.e. no stopping the debugger inside and no reporting errors of PB commands inside.
DisableDebugger
Procedure MyLibFunction()
  
  PB_DEBUGGER_SendError("A debugger error")
  ;PB_DEBUGGER_SendWarning("A warning for you")

EndProcedure
EnableDebugger


Procedure CallerProcedure()
  MyLibFunction()
EndProcedure

CallerProcedure()

[STARGÅTE]

The reporting behavior in your posted code example is exactly what I was looking for, thanks for this snippets.
And adding a DisableDebugger can easily added by a CompilerIf commant for developer-mode oder user-mode.

However, using this work-around with import of PB_DEBUGGER_SendError and PB_DEBUGGER_SendWarning is not very clean. Perhaps, there is a way to add a Flag to DebuggerWarning() to prevent this ignoring within a DisableDebugger block?