Simple Try/Catch (As long as it is not integrated yet)

[mk-soft]

From Features Requests...

Code: Select all

;- Try/Catch by mk-soft version v1.2

#State_IsDebugger = #PB_Compiler_Debugger

Macro Try
  CompilerIf #State_IsDebugger
    DisableDebugger
  CompilerEndIf
  OnErrorGoto(?LabelCatch#MacroExpandedCount)
EndMacro

Macro Catch
  Goto LabelEndTry#MacroExpandedCount
  LabelCatch#MacroExpandedCount:
  OnErrorDefault()
  CompilerIf #State_IsDebugger
    EnableDebugger
  CompilerEndIf
EndMacro

Macro EndTry
  LabelEndTry#MacroExpandedCount:
  OnErrorDefault()
  CompilerIf #State_IsDebugger
    EnableDebugger
  CompilerEndIf
EndMacro

;- Test

Try
  B = 100
  A = B / 10
Catch
  A = 0
EndTry
Debug A

Try
  B = 0
  A = 10 / B
Catch
  Debug ErrorMessage()
  A = 9999  
EndTry
Debug A

[Sicro]

Nice improvements

But as with the codes in the german forum thread, this try-catch workaround has problem with the following code, too:

Code: Select all

Try
  CallFunctionFast(50)
Catch
  MessageRequester("Error", "An error has occurred!")
EndTry

[JHPJHP]

Hi mk-soft,

You have exceptional programming skills

-----------------------------------------

Here is a Windows Only version by Danilo:
- [Windows XP+] Try .. Catch .. EndTry - Error Handling

[mk-soft]

Many Thanks,

Try to stay fit in Purebasic. In the work I mostly only with SPS programming or VB script to do.
It rarely happens that I write with Purebasic for industrial applications or services programs.

[mk-soft]

Nice improvements

But as with the codes in the german forum thread, this try-catch workaround has problem with the following code, too:

Code: Select all

Try
  CallFunctionFast(50)
Catch
  MessageRequester("Error", "An error has occurred!")
EndTry

For this case, we have to look at how we can save all register before and restore it in the event of a failure

[Sicro]

All Try-Catch workarounds via macros and the PB-OnErrorLib should be viewed only for the fun of programming and should not be used in productive use because they are not safe to use:

The program stack will not be adjusted before jumping to the label, so local variables should not be accessed as they may not be reachable anymore. It is also not safe to continue normal program execution after an error as things like the return address of a procedure may be wrong if the stack is no longer correct. The best practice is just to gather and display information about the error and then exit the program.

Source: http://purearea.net/pb/english/manual/o ... rgoto.html

I think the best way we can go currently is to manipulate the asm output from pb before fasm gets it. It's the way the forum member Rings went, if I'm not mistaken.