ProcedureReturn statement...

[Dudemeister]

@BarryG

My apologies to you, as well, especially if I have unintentionally offended anyone. I feel I may have caused a misunderstanding in my use of terminology, whereas I'm an old school American programmer and we differentiate between exceptions (expected/foreseeable errors) and unexpected errors.

Because PureBasic reminds me of my old days in Assembly and C, and because of the incredible speed in its compiled apps, I do hope I can find a way to work around this one issue of apps exiting after a critical error and continue working with PureBasic.

[Dudemeister]

@skywalk

Dudemeister, you sound a lot like

https://www.purebasic.fr/english/viewtopic.php?f=3&t=73592

Will you be asking to delete your forum account now that you determined PB unworthy of your investment
Yes, I use PureBasic for complex control systems and the usual database apps.
I come upon many, many errors and log them.
My crashes are seldom, but a few recent ones were from power outages or referencing a map element that does not exist.

Umm... no. I've already purchased PureBasic. I'm at least going to tinker with it even if I don't use it in my commercial applications.
The link you posted referenced Try-Catch error handling. I've not been a fan of that hackery since it became a thing - mostly because of the overhead in its implementation. We handle international financial transactions and all of our systems are on universal backups which give us plenty of time to complete any in-progress transactions, then shut down our systems. So, power outages are never a concern for us. Additionally, all 6 servers are backed up sequentially every 60 minutes. However, because of the nature of our data, applications which exit following a critical/unexpected error are somewhat of a concern for us. Any other issues or unsupported features in the language can easily be worked around with a bit of imagination. But I've never really faced this particular issue before and my team is going to have to do a lot of creative thinking before we can make any move to replace our bloated mixture of Visual Studio, Access, ASP.NET, and SQL Server. We are working to transition to a desktop development system for streamlined but secure apps that link well with both SQLite (local databases) and MySQL (server database). Node.js and JavaScript will handle the stack. C++/Qt is a viable option and is the current leading contender, but possesses nearly as much bloat as the .NET eco system. I'm also looking at PB right now because of the speed of its compiled executables, as well as it being cross-platform. This one is important so that we maintain the option of switching operating systems in the future with as little effort as possible. Yes, .NET is cross-platform, but not to a reliable enough extent for us. And did I mention it's as slow as a turtle?

[skywalk]

Whew! Glad you are not that other guy. Welcome.

Even if you only decide to prototype in PureBasic, you will blaze ahead.

Try-Catch is not to be dismissed. I would welcome it in PureBasic, and it is central to many modern languages.

My power outage problem was only a few instruments lost their connection state while my PC was happily cruising along. So, that caused a lot of error logging and many keystrokes to exit the app.

[BarryG]

hope I can find a way to work around this one issue of apps exiting after a critical error and continue working with PureBasic.

Hi again. So what's crashing, exactly? PureBasic is very stable if coded correctly, and won't just crash for no reason. My main app is currently 2 MB of source code (34000+ lines, plus over 330 embedded images and sounds), with 4 main windows and up to 20 different threads running simultaneously at any time... and it's all rock-solid; from Win XP to Win 10, 32-bit and 64-bit. My app's never had a crash that wasn't my fault in the code. PureBasic will be able to handle anything you throw at it, as long as you test for all error conditions. That's why I'm wondering what type of unexpected errors you're talking about?

[Mijikai]

hope I can find a way to work around this one issue of apps exiting after a critical error and continue working with PureBasic.

If thats the only reason i suggest you code your own error handling routines?
Btw. i also dont really get your issue.

[Little John]

I can handle exceptions quite well, thank you. I am merely concerned with, and reasonably so, a PB app wanting to exit following an unforeseen critical run-time error. If the way PB handles critical errors works for you gentlemen, then I say good for you. I'll buy you a drink. However, when I mention that it doesn't work for what I need, ...

Here, for the first time in this thread, you are expressing what you are really concerned about.

For handling critical run-time errors, PureBasic has its "OnError" library.
What problems do you exactly encounter when using that library? Do you expect your PB program to continue smoothly after a critical run-time error (e.g. a memory corruption)? If this were possible, then that error probably wouldn't be called "critical", no?

[Bitblazer]

Every single access on potentially random external data could be toxic and potentially crash unexpected elements of your software. In the past that has happened with dozens of archive and image formats, but also with text data formats as they too became more and more complex and therefore began to include compressed data. A bit unexpected to me was this recent crash issue (Linux library access problem). But the common factor basically is - access of potentially random external data. Many internal commands rely on triggering a heap of external routines through libraries or via API's.

Add the "softer" problems of stuff like sql injections and you know the mutual factor is simply - external data And to make it funnier, many API based calls can trigger those too.

And every sane developer knows that it is a really stupid idea to implement file formats which basically trigger API calls with parameters taken from their own binary streams. (Yes a huge Redmond based company did that).

Whenever you access external data, all kind of "funny" stuff can happen.

[mk-soft]

Critical errors are, for example, when two identical servers on the network, one server on the weekend when no one is there, suddenly feel they are no longer connected to a known network. So he changes his permission on the network and a service of mine that runs as a network service has no permission to exchange data and write logfiles.

No such good error management helps.

The service now runs under another user.

[Bitblazer]

Sounds like a Layer 8 problem. Life is a competition between software engineers to make better software and the universe to make worse users. So far the universe wins :s

[Michael Vogel]

Interesting thread - my time for writing commercial programs is far behind. When programming I needed to handle all kind of errors (file, networking, memory, interrupts, output devices) but I never handled this by using constructs like try/catch.
Maybe this is a new programming style, for me try/catch sounds a little bit like quick and dirty coding as you don't need to understand all things which could go wrong during runtime - building a program which stays in a kind of debugging mode for the whole time...

[Dudemeister]

Sounds like a Layer 8 problem. Life is a competition between software engineers to make better software and the universe to make worse users. So far the universe wins :s

I think this one wins! LMAO

[Dudemeister]

Okay, after a year and a half away I am picking this puppy (PureBasic) back up.

The main issue I have when tinkering with PB is that the built-in error handler exits after an unexpected error occurs, even though sometimes it may not be a critical error. I know this won't be changed, as I have read elsewhere in the forum that the Resume() command was removed some time ago.
Additionally, the error handler command(s) in the label (ErrorHandler:) seem to execute in a sort of loop on my machine - a total of 5 times before exiting the program. I'm not sure that is intended behavior.

Code: Select all

Procedure.l MyFunction()
   OnErrorGoto(?ErrorHandler)   
   
   MessageRequester("Error Test", "Hello, cruel world!", 0)
   
   PokeS(10, "Hang on! We're gonna crash!") ; Cause a #PB_OnError_InvalidMemory error
   
   ProcedureReturn -1
   
ErrorHandler:
   
   ;This statement repeats for a total of 5 executions before finally exiting the program.
   MessageRequester("Error Test", "The following error happened: " + ErrorMessage(), 0)
   
   ProcedureReturn 0 ;This error value will not get returned to the calling procedure.
EndProcedure

If OpenWindow(0, #WIN_SIZX, #WIN_SIZY, #WIN_INRW, #WIN_INRH, #STR_CPTN, #PB_Window_SystemMenu | #PB_Window_MinimizeGadget | #PB_Window_MaximizeGadget)
   MessageRequester("Error Test", Str(MyFunction()), 0)
   
   Repeat
      Event = WaitWindowEvent()

      If Event = #PB_Event_CloseWindow  ;If the user has closed the main form.
         Quit = 1
      EndIf
   Until Quit = 1  
EndIf

End ;Completely terminate program.

[Dudemeister]

This Try/Catch error handling structure by Danilo https://www.purebasic.fr/english/viewtopic.php?t=49903 works very well at continuing with the program's execution following an un expected error. Yet, unfortunately, it doesn't seem accommodate any means I can see to extract either the error number or the error description.

Code: Select all

Procedure.l MyFunction()
   Try
      MessageRequester("Error Test", "Hello, cruel world!", 0)
      
      PokeS(10, "Hello, cruel world!") ;Cause a #PB_OnError_InvalidMemory error
      
      ProcedureReturn -1
   Catch
      MessageRequester("Error Test", "An error happened, but we don't know which kind.", 0)
      
      ProcedureReturn 0 ;This error value does get correctly returned to the calling procedure.
   EndTry
EndProcedure

If OpenWindow(0, #WIN_SIZX, #WIN_SIZY, #WIN_INRW, #WIN_INRH, #STR_CPTN, #PB_Window_SystemMenu | #PB_Window_MinimizeGadget | #PB_Window_MaximizeGadget)
   Try
      MessageRequester("Error Test", Str(MyFunction()), 0)
   Catch
      MessageRequester("Error Test", "No error should occur here regardless if one occurred in the MyFunction() routine.", 0)
   EndTry

   Repeat
      Event = WaitWindowEvent()

      If Event = #PB_Event_CloseWindow  ;If the user has closed the main form.
         Quit = 1
      EndIf
   Until Quit = 1  
EndIf

End ;Completely terminate program.

Ideally, however, Danilo's setup would be expanded and optimized to include an 'exception' class, collection, or something to allow for extracting the error data. Such as:

Code: Select all

Procedure.l MyFunction()
   Try
      MessageRequester("Error Test", "Hello, cruel world!", 0)
      
      PokeS(10, "Hello, cruel world!") ;Cause a #PB_OnError_InvalidMemory error
      
      ProcedureReturn -1
   Catch Exception
      MessageRequester("Error Test", "An unexpected error occurred!" + #CRLF$ + "Error Code: " + Str(Exception.Code) + #CRLF$ + Exception.Message, 0)
      
      ProcedureReturn 0 ;This error value does get correctly returned to the calling procedure.
   Finally ;This part would be completely  optional for the coder to include only when necessary.
      ;DO SOMETHING HERE...
   EndTry
EndProcedure

The Exception collection member would look something like this.

Code: Select all

Exception.Address ;String(?) read-only property - returns the address of the code where the error occured.
Exception.Clear() ;Procedure method - clears all data from the error/exception information collection.
Exception.Code    ;Integer read-only property - returns the number or code which uniquely identifies the error.
Exception.File    ;String read-only property - returns the filename (possibly even the full path) of the file in which the error occured.
Exception.Line    ;Integer read-only property - returns the number of the line where the error occured.
Exception.Message ;String read-only property - returns a brief description or summary of the error.

I'm not sure that Exception.File property is warranted. I only included it because of PB's existing ErrorFile() command.

The last requirement is that it be cross-platform. I couldn't tell simply from the code if Danilo's masterpiece is cross-platform or is MS Windows dependent.

Anyway, the beautiful thing about this is... we wouldn't need Fred or Fantaisie Software to make this a full part of PB. We - the PB community - could work on finishing out this creation and providing it either as a DLL or an include file. Fantaisie Software could distribute it with PB if they wanted, or not have anything at all to do with it.

Why? While a few hard-nosers and purists in this forum have stated they prefer the program exit out following an error because they falsely believe a good programmer would design their program to be rid of such bugs, there are also many of us who see that some data-critical programs (financial and military, for example) MUST include structured error handling or not even be bothered with.

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.

Thoughts from the community?

[mk-soft]

This purebasic has been stable for years in productive systems in the areas of data acquisition and communication.

The purebasic functions return the success of the action directly and do not need any extra OnErrorHandling like in VB where you have to ask for a function after executing it.
The ErrorHandle of PB catches critical errors. After an error, the programme should be terminated.

PB-Help

Syntax

OnErrorGoto(?LabelAddress)
Description
Changes the action taken when an error occurs to jump to the specified label address and continue program execution there. After the jump to the label, the functions of this library can be used to get further information about the error.
Parameters

?LabelAddress The address of a label in the program to jump to.
Return value

None.
Remarks

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.
Example

MessageRequester("OnError test", "Test start")

OnErrorGoto(?ErrorHandler)
Pokes(10, "Hello World") ; Cause a #PB_OnError_InvalidMemory error

MessageRequester("OnError test", "This should never be displayed")
End

ErrorHandler:
MessageRequester("OnError test", "The following error happened: " + ErrorMessage())
End

[Dudemeister]

You and others keep saying this. So, I'm just going to ignore you and those who share your opinion from this point.
If you don't like the feature I mention, life is simple... don't use it and leave others alone who might want it.

It's not for you. But thanks for your input.