Page 3 of 3
Re: ProceureReturn statement...
Posted: Sun May 23, 2021 3:25 am
by 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.
Re: ProceureReturn statement...
Posted: Sun May 23, 2021 3:39 am
by 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.
Re: ProcedureReturn statement...
Posted: Sun May 23, 2021 11:39 am
by freak
Dudemeister wrote: Sun May 23, 2021 2:44 amI 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.
Re: ProcedureReturn statement...
Posted: Sun May 23, 2021 4:40 pm
by 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.
Re: ProcedureReturn statement...
Posted: Sun May 23, 2021 4:53 pm
by Tenaja
Dudemeister wrote: Sun May 23, 2021 4:40 pm
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.
Re: ProcedureReturn statement...
Posted: Sun May 23, 2021 4:59 pm
by Dudemeister
He is entitled to his own opinion.
Re: ProcedureReturn statement...
Posted: Sun May 23, 2021 5:23 pm
by 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.
Re: ProcedureReturn statement...
Posted: Tue May 25, 2021 7:11 pm
by 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.
Re: ProcedureReturn statement...
Posted: Tue May 25, 2021 7:40 pm
by 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.
Re: ProcedureReturn statement...
Posted: Tue May 25, 2021 8:44 pm
by freak
Why the hostile attitude? Did we do anything to you?
Re: ProcedureReturn statement...
Posted: Tue May 25, 2021 9:00 pm
by 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.
Re: ProcedureReturn statement...
Posted: Wed May 26, 2021 3:33 pm
by 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?
Re: ProcedureReturn statement...
Posted: Wed May 26, 2021 10:06 pm
by 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.
Re: ProcedureReturn statement...
Posted: Thu May 27, 2021 1:48 am
by 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.
Re: ProcedureReturn statement...
Posted: Mon May 31, 2021 11:19 am
by 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.