Handling Try/Catch

[SergeyA]

Hello, please add support for handling exceptions. Try/Catch

[IdeasVacuum]

Encourages the use of a sloppy coding style

[ts-soft]

+1
for try / catch

[Manuel]

Can someone explain the practical difference between these two sets of codes? Because I fail to see why Try/Catch is needed, especially when it adds more typing and code.

Code: Select all

Try
  PokeL(0, 12345)
Catch
  ErrorLog("Write to zero address")
EndTry

Code: Select all

If PokeL(0, 12345) = 0 ; Failure.
  ErrorLog("Write to zero address")
EndIf

[RSBasic]

+1
Please Catch with Exceptions.

[wilbert]

Can someone explain the practical difference between these two sets of codes? Because I fail to see why Try/Catch is needed, especially when it adds more typing and code.

Code: Select all

Try
  PokeL(0, 12345)
Catch
  ErrorLog("Write to zero address")
EndTry

Code: Select all

If PokeL(0, 12345) = 0 ; Failure.
  ErrorLog("Write to zero address")
EndIf

PokeL has no return value so the second approach makes no sense.
Try / Catch is useful in a lot of cases for example when working with external libraries.

[Mijikai]

+1
would be great to have

[Shield]

Can someone explain the practical difference between these two sets of codes?

While I am certain that exceptions never make it into PB, here are some advantages exceptions would offer:

• Actually less typing because not every function has to be checked for errors (i.e. they can be grouped).
• It is possible to differentiate between different error types (groups).
• Exceptions can bubble up the call stack.
• Exceptions can be handled where appropriate instead of directly at the call site.
• Exceptions must be handled. If not handled, the program will ultimately abort. While this may sound drastic,
  it is actually a much better option than silently ignore an error that may crash the program later anyways.
• Better separation of code and error handling.
• Arguably better performance if no exceptions occur (exceptions can be implemented with zero runtime overhead).

[SergeyA]

This option does not work, the application is shutting down.

Enable debugger:


Disable debugger:


Reference:

[Manuel]

PokeL has no return value so the second approach makes no sense.

True, so that was a bad example. I've seen other Try/Catch examples where the tested item does have a return value (such as "Try LoadImage..."), so I should amend my question to be: how is Try/Catch better in those cases than If/EndIf?

[wilbert]

I should amend my question to be: how is Try/Catch better in those cases than If/EndIf?

It is not useful in case of LoadImage since LoadImage doesn't throw an error but returns zero when it fails.
Try/Catch is useful for those situations where an error can occur that isn't handled by PureBasic so the application doesn't crash.

[chi]

+1

[Manuel]

Try/Catch is useful for those situations where an error can occur that isn't handled by PureBasic so the application doesn't crash.

So it's like the "Trap" command of some older Basics, or "On Error Resume Next" of Visual Basic Classic?

[SergeyA]

Try/Catch allows you to capture application errors without affecting the application, you can collect error data and issue corrected updates for your clients.

[DarkDragon]

I'd especially need a Finally clause for cleaning up when the procedure ends in cases where many procedurereturns exist. This is very useful.