PureBasic Forum

The following is an example of an ideal Try/Catch code block. Because I am just now learning PB, I don't know if it will work well with this language, but in other languages it allows for some spectacular error handling. Combined with events, it also allows the coder to decide where and the best manner in which to deal with the error.

Example:

Procedure MyProcedure(Param1, Param2)
    Protected.i intErr

    Try ;attempt the following code...
        DoSomething() ;normal code here...
        DoSomethingElse()

        intErr = #False ;indicate no error occurred...
    Catch ;handle any raised errors...
        If ErrorNumber <> -1 ;if any error other than successful execution is returned...
            PostEvent(#EventRaiseError) ;trigger the RaiseError event to allow coder to decided the best place and manner to deal with the error.
        EndIf

        intErr = #True ;indicate an error occurred...
    Finally ;(This segment would be optional for the coder to use) execute the following code no matter what so coder can decide how to best proceed with program execution or shut down...
        CloseDocument() ;safely close document/encrypted data file to prevent data loss and corruption...

        If intErr = #False ;if no error occurred...
            ProcedureReturn ThisValue ;return some value determined by program execution...
        Else ;if an error occurred...
            ProcedureReturn ThatValue ;return a different value determined by the type of error...
        EndIf
    EndTry
EndProcedure

Why?

The first thing I learned in Java was: Nothing is more expensive than try/catch and a Null-Check.

You can check every variable and pointer on 0. If there is an IMA, than someone miss this check, miss filling the memory or an memory error.

When you write clean code, you don't need the communication over Exceptions.

Why? Because the encrypted data of my clients is worth more than your opinion.
If you don't like a feature or other people's method of programming - don't use it.
And given Java's history of bugginess, along with the spaghetti code development style of a large portion of the hipsters who use it, Java isn't exactly the best example to bring up when trying to persuade someone that extensive handling methods aren't necessary.
But hey... as long as Java is used, IT workers continually having to fix crashed systems will always have job security. Just ask Amazon...

Just a quick attempt:-



Maybe what you are looking for?

CD

@collectordave

That is great work, and I appreciate it. So, thank you very much for your help!!

Unfortunately, however, when an error is raised in a PB procedure, something prohibits it from returning a value - the OnErrorResume() command was deprecated at some point. When working with enterprise-level data objects, the ability for a function to return a value even in the event of an error is EXTREMELY crucial, which is why it is implemented in enterprise-level languages. As Cyllceaux mentioned, the Try/Catch/Finally block is a bit expensive on system resources and program execution speed. However, with data-critical apps, well, the stability and security of the data is worth more than the speed.

One reason I have really been looking into PB is because of the blinding speed of its compiled executables. Most languages which use Try/Catch/Finally are either bytecode (Java) or common intermediate language (C#/CIL - Microsoft's version of bytecode which is actually based on Turbo Pascal/Delphi by their creator Anders Hejlsberg) executing via a virtual machine, so they're just naturally slow at execution to begin with. If PB had Try/Catch/Finally, any programs compiled using it - even on a bad day - would still blow away a C# or Java app on their best days.

If PB functions could return a value following an error, then your example would work great for me.

Errors caught by OnError are almost always fatal so quitting is the only option. Check the on error documentation.

However you can raise your own errors and deal with them.

Try This done for mac as on windows you can use raiseerror()

Regards

CD

Everyone other than myself seems to keep missing the point.
I know most run-time errors are fatal and the app needs to shutdown. However... and this is the main point... the function in which the error occurs still MUST return some value to its calling function due to the type of data objects I'm connected to, after which point I can shut down the app.

It's not that I just want this ability. It's a non-negotiable requirement for my work, which is why I'm more than likely going to have to go with ObjectPascal/Delphi which I'm familiar with and it is already well equipped for enterprise development.

Because of its speed and lack of bloat, PureBasic has the opportunity to be a goldmine with 3 or 4 simple added features whereby it would take up the mind-share of VB6 development, as well as stealing away quite a bit of VB.NET/C# development. But I guess Fred has his reason for not wanting to go there.

I am surprised you did not search "TRY Catch" many people suggested

If PB is fast and light, it is precisely because he doesn't bother with all these checks.

There are only two public for PB

• Beginners (who do not handle user errors)
• Experienced (sometime professionals) who know how to handle errors without "trial and error" (try/catch)

The "On Error" lib and the IsXXX(1) functions are sufficient to make stable programs. All native PB functions return a value.

And we've been doing this for over 20 years in PB

(1) IsBillboardGroup, IsCamera, IsDatabase, IsDialog, IsDirectory, IsEffect, IsEntity, IsFile, IsFingerprint, IsFont, IsFtp, IsGadget, IsGadget3D, IsImage, IsInfinity, IsInsidePath, IsInsideStroke, IsJSON, IsJoint, IsLibrary, IsLight, IsMail, IsMaterial, IsMenu, IsMesh, IsMovie, IsMusic, IsNaN, IsNode, IsParticleEmitter, IsPathEmpty, IsProgram, IsRegularExpression, IsRuntime, IsScreenActive, IsSerialPort, IsSound, IsSound3D, IsSprite, IsStaticGeometry, IsStatusBar, IsSysTrayIcon, IsText3D, IsTexture, IsThread, IsToolBar, IsWindow, IsWindow3D, IsXML

Agree, for Windows it's valid native way and also flexible one.

Foot Doctor: "You brain surgeons don't really need such and such tool to perform your surgery."

Brain Surgeon: "How do you know we don't need such and such tool to perform our work. Do you perform surgery? And do you perform the same type of surgery we do?"

Foot Doctor: "No, not at all. And that's precisely how I know you don't need such and such tool, because we don't use it. I'm qualified to say what you do or don't need based on what I do because we're both physicians, right?"

In the beginning of this thread, it looked as if you wanted to start a serious discussion ...

@skywalk



I have attempted to use many Try/Catch macro samples from the forum, but none have worked so far because they still did not allow the function to return a value if an error occurred. This is my first time seeing Danilo's version. I just tested it a few times and it does allow my functions to return a value, but ErrorCode() always returns a -1 (no error) when using it. I still need the error code and error description in addition the ability to return a value in the event of an error. So, unfortunately, it's no good to me either.

@Marc56us

"The "On Error" lib and the IsXXX(1) functions are sufficient to make stable programs. All native PB functions return a value."

Using all the example I could find using PB's 'OnErr' library, I could not get my functions to return a value after an error was raised without a Resume command. Maybe I downloaded a different version of PB than everyone else, but I doubt it.

Anyway, skywalker pointed me to Danilo's version of the Try/Catch and it works great.

@ Little John



It is a serious discussion. It's just that as is often the case in programming forums, other programmers were more interested in flexing their fragile egos by telling me what they thought was the right way to do things rather than helping me figure out a way to meet my requirements.

skywalker helped meet achieve my goals, this particular one for which there is no negotiation. It is either find a way to meet this requirement in PB, or throw PB out the window and go on to another language.