ProcedureReturn statement...

[mk-soft]

Edit ...
To intercept critical areas I use the double thread procedure. One thread for processing and one as a watchdog thread. No OnErrorHandle helps if an external function runs into nirvana. Unfortunately, I have already had this happen with an external data interface.

A PB internal better try catch has already been requested. But I have always managed without one until now.

[Dudemeister]

I'm confused...

If you don't want to use such a feature, that is okay. But WHY are you so adamant against myself and others who have mentioned it seeking to find a way to properly implement it? What does it hurt you? I cannot think of one possible reason why someone else developing a feature you may not use should get you in such a tizzy. No one is asking you to take part or pay any money. Your behavior wreaks of control and/or superiority issues.

[freak]

I was pondering the idea of starting a crowd-funded monetary prize for whomever first develops a complete, cross-platform, and bug-free try/catch error handling system for PureBasic that would be distributed freely to the community. I haven't done it yet. But I'm thinking about it.

You cannot do that correctly without the help of the compiler because you will get memory leaks very quickly if you go beyond the very simple examples shown so far. Have a look at this example:

Code: Select all

Procedure.l SomeOtherFunction()
  
  ; this will allocate some memory
  SomeLocalVariable$ = "Hello World" 
  
  ; this will cause the procedure to be left without the compiler generated cleanup of local resources at procedure end. 
  ; The contents of "SomeLocalVariable$" are leaked
  PokeS(10, "Hello, cruel world!") 
  
EndProcedure

Procedure.l MyFunction()
   Try
      SomeOtherFunction() ; memory leak inside
   Catch Exception
      ; whatever
   EndTry
EndProcedure

This can only be solved with the help of the compiler: The compiler must generate a hidden "Try/Catch" block in every procedure that takes care of freeing resources if an exception happens to guard against memory leaks.

But this is actually the smaller problem here. Even if the compiler helped, you as the programmer would need to be aware and cleanup EVERY piece of data that you allocate yourself to ensure that it is properly freed in the face of an exception. Take this example:

Code: Select all

Procedure.l SomeOtherFunction()
  
  ; allocate image
  ; Note: This is not a compiler managed resource, so the compiler cannot help you with automatic cleanup!
  ; You have to ensure yourself that FreeImage() is called eventually
  MyImage = CreateImage(#PB_Any, ...) 
  If MyImage
    
    ; oops, a mistake
    PokeS(10, "Hello, cruel world!") 
    
    ; never reached. MyImage is leaked
    FreeImage(MyImage)
    
  EndIf

EndProcedure

Procedure.l MyFunction()
   Try
      SomeOtherFunction() ; memory leak inside
   Catch Exception
      ; whatever
   EndTry
EndProcedure

You have to manually add a Try/Catch in SomeOtherFunction() to ensure that it can be used anywhere in the code that has a Try/Catch so no memory leaks are introduced. Now this is simple in such an example, but as soon as your program gets more complex this becomes an impossible task. Manually ensuring that all code that can be reached from a Try/Catch block is properly guarded against leaks is simply not possible if you develop and change a large program over any larger period of time (or with more than one developer). There WILL be memory leaks at some point, even if you make it a habit to always add Try/Catch to ALL code that allocates some resource in your entire program: miss one spot and you have a possible leak. And a memory leak can crash your program too.

As you can see, this feature actually makes it a lot harder to write bug-free code that without it. This is why it does not exist in PureBasic.

All this is no problem in a language with garbage collection because anything you leave behind will just be cleaned up by the GC. This is why exception handling is very popular in garbage collected languages and VERY few languages without a GC have this feature.

[Dudemeister]

This argument is invalid, as a memory leak would occur in a language without garbage collection if the programmer doesn't manualy clean up/dispose of the object regardless of whether he is using OnErrorGoto(), Try/Catch/Endtry, or no error handling mechanism at all. Your examples have nothing to do with the error handling mechanism being used but, instead, has everything to do with the individual programmer's methodology and style.

Even if your example were to have been even partially valid, the argument you put forward is akin to saying that automobiles should not be manufactured because numerous owners/operators never bother to check the oil, thereby causing their engines to blow up. What one group of people fail to do should not dictate whether a useful utility is made available to others.

[Tenaja]

This argument is invalid, as a memory leak would occur in a language without garbage collection if the programmer doesn't manualy clean up/dispose of the object regardless of whether he is using OnErrorGoto(), Try/Catch/Endtry, or no error handling mechanism at all. Your examples have nothing to do with the error handling mechanism being used but, instead, has everything to do with the individual programmer's methodology and style.

Even if your example were to have been even partially valid, the argument you put forward is akin to saying that automobiles should not be manufactured because numerous owners/operators never bother to check the oil, thereby causing their engines to blow up. What one group of people fail to do should not dictate whether a useful utility is made available to others.

You do realize Freak is one of the developers, right? So he really does know what he's talking about.

And what I read was not that it couldn't be done, but it couldn't be done by a third party developer.

[Dudemeister]

He is entitled to his own opinion.

[freak]

There is a big difference between the two because the presence of Try/Catch adds additional invisible execution paths to a procedure because a procedure can exit any time due to an exception:

Code: Select all

Procedure Something()
   
  ; might cause an error and an early procedure exit via exception which is caught somewhere further down the stack
  DoSomething() 
      
  ; may be executed, may be not. This is not really obvious
  DoMoreStuff()
   
EndProcedure

In contrast, this is more explicit if no exceptions exist:

Code: Select all

Procedure Something()
 
  ; early exit of the procedure is explicit
  If DoSomething() = 0
    ProcedureReturn 0
  EndIf
    
  ; it is more obvious that this might not be executed here
  DoMoreStuff()
 
EndProcedure

Especially when it comes to proper cleanup of resources (but also in other cases) it helps a great deal to make the possible exit points of a procedure explicit.

Anyway, I am not trying to change your mind. Just trying to explain the reasoning why this feature does not exist in PB.

[Olli]

Personnally, I never used OnError library for the error management.

As an error causes a null value, here is a small example.

Code: Select all

Procedure Err(Mess.S)
  MessageRequester("Error", Mess)
  End
EndProcedure

If ExamineDesktops()
  If InitSprite()
    If OpenScreen(DesktopWidth(0), DesktopHeight(0), 32, "")
      If StartDrawing(ScreenOutput() )
        DrawText(0, 0, "Graphic screen")
        StopDrawing()
        FlipBuffers()
        Delay(3000)
      Else
        Err("Draw error")
      EndIf
    Else
      Err("Screen error")
    EndIf
    Err("SubSystem error")
  EndIf
  Err("Desktop error")
EndIf

There are no other errors as what we call. If there would be an other error, it is because I made a bug in the source code.

A careful must be specificly done for the functions not returning a value (FlipBuffers, DrawText, etc...). The main part of the time, it is a domain problem (memory, direct or not), but I must prevent it from occur.

[Dudemeister]

So, in your bubble:

- memory can't become corrupted by a power surge (not power outage) while running the software?
- hard disk drives never fail while using your software?
- networks/internet never fail while using your software?
- motherboards/communications ports never fizzle while using your software?
- users never use software for unintended purposes?
- 3rd party peripherals/hardware your software needs to access never freezes up while using your software?

Not a single one of the instances I listed above are related to the ones you listed, yet they produce runtime errors in the software which may or may not be critical depending on the circumstances but almost always require allowing the user to save critical data and close out encrypted configuration critical files to prevent corruption before the program abruptly ends, and they happen quite regularly.

Wow... I envy your magical world.

[freak]

Why the hostile attitude? Did we do anything to you?

[Dudemeister]

@freak

I am not sure I am being hostile. In fact, I am quite jovial but I feel others have been hostile to me for asking about a means structured error handling.

I understand why so many of you don't want to use it, and I've heard all the arguments before. However, if you don't want a particular feature, please do not attempt to dissuade someone else from inquiring about it. The programming methods of the experienced PB users are not a golden egg, they are simply a different means to achieve a stated goal.

[skywalk]

This is a good discussion on PROS and CONS of TRY/CATCH.
Coming from VB6 way back, I wondered where was ONERROR Goto?
But, focusing on the trappable errors in my code, I reduced the complexity and buggyness of my PB equivalent code.
True, I have to throw a white flag of surrender at a catastrophic error, but those are fewer than you think and do not warrant the hidden control flow Freak talked about.
I really don't like any hidden aspects in PB.

Dudmeister - Can you show some code with and without your TRY/CATCH scenario?

[Bitblazer]

Sounds like you either need to make sure your hardware never fails, or that you need a fault tolerant language like Erlang / Elixir.

Both requirements are far beyond a simply try/catch mechanism.

[Dudemeister]

@Bitblazer

Try/Catch deals with system errors quite well in other languages.

Sounds like you either need to make sure your hardware never fails...

Perhaps I should ask Harry Potter to wave his magic wand and make that happen.

This is my last post on this particular thread. It's going nowhere.

[Rinzwind]

Just came pass Google’s view on exceptions…
https://google.github.io/styleguide/cpp ... Exceptions

They don’t allow them in their code.

Anyway, PB does not have the facilities buildin. PB is very comparable to C, just with some handy shortcuts. I personally wish it did extend its syntax a bit to support common data/behavior paradigms.

You can use a label and goto statements to always have one exit point from procedures where cleanup can take place.