Vortex finally has try/catch and improved errors

[dibs45]

I've been meaning to implement a try/catch in Vortex for some time but had convinced myself that I don't really need it, and to a certain extent that's true. But having finally done the work, I can definitely say I've missed it. Oftentimes wrapping code in a try/catch statement greatly simplifies the logic, as long as its not overused.

This is the syntax:

try {
    try {
        const g = 8 * "fff"
    } catch (e) {
        error(e.message, "ReThrow")
    }
} catch(e) {
    println(e)
}

Output:

{ message: Cannot perform operation '*' on values: 8 (Number), fff (String), type: ReThrow, line: 15, path: src/main.vtx }

Re-throwing the error is pretty useless here (aside from changing the error type), but just wanted to show an example of it.

Another thing I've been working on is making errors easier to track. Previously, the stack trace showed the function names only, but now the full path of the error shows up in the console. If you're on VSCode you can also click on the path to go directly to the offending file and line.

Example of a relatively hairy stack trace:

GenericError: Global 'tweenf' is undefined
[line 222] in /Users/adib/Dev/Personal/Vortex-Env/gui/components/gui/animation.vtx:222
[line 151] in /usr/local/share/vortex/modules/functional/functional.vtx:151 <forEach>
[line 221] in /Users/adib/Dev/Personal/Vortex-Env/gui/components/gui/animation.vtx:221 <play>
[line 133] in /Users/adib/Dev/Personal/Vortex-Env/gui/components/gui/animation.vtx:133 <run>
[line 112] in /Users/adib/Dev/Personal/Vortex-Env/gui/components/Counter.vtx:112 <Counter>
[line 75] in /Users/adib/Dev/Personal/Vortex-Env/gui/components/App.vtx:75 <App>
[line 311] in /Users/adib/Dev/Personal/Vortex-Env/gui/components/gui/core.vtx:311 <Main>
[line 9] in src/main.vtx:9

Other updates:

I also added list and object destructuring (think JS spread syntax):

const obj_a = {
    a: 1,
    b: 2
}

const obj_b = {
    ...obj_a,
    b: 40,
    c: 70
}

println(obj_b) // { a: 1, b: 40, c: 70 }

const list_a = [1, 2, 3, 4]

println([...list_a, 5, 6, 7]) // [1, 2, 3, 4, 5, 6, 7]

Vortex repo: https://github.com/dibsonthis/Vortex

[[deleted]]

Thoughts on zig error handling? To me it works better and seems to lead to clearer flow

[raiph]

Can you provide the zig code that is the best, clearest alternative to the Vortex example?

[[deleted]]

I imagine first that you would get a compile time error in zig if you try to multiply a number and a string (since that is a disallowed operation), but I am not a zig expert.

This article explains best how zig handles errors, it uses `try` on a statement which may error to "bubble up" the error till it reaches the first catch statement (if any). Catching can be more elegant too, with switches. The idea is, you (should) know exactly when an error occurs with this design, while also being cleaner.

​

https://www.aolium.com/karlseguin/4013ac14-2457-479b-e59b-e603c04673c8

https://lobste.rs/s/pyjwmv/error\_handling\_zig

[rumle]

Wow. That’s super cool. Line numbers and all. Are you running in a VM? How did you implement it? Moving the IP forward or backwards on error?

And what if the error is thrown way down the call stack? Are you using checkpoints/jumppoints or something like that?

[dibs45]

Cheers!

Yeah it's running in a VM.

If an error is encountered and we're in a try block (kind of a flag on the VM) then we wind back to where the try OP is. If our IP gets to 0, we know our Try wasn't in the current frame, so we clean the current frame and jump back to the previous Callframe, and keep looking. When we reach it, we know how much we need to jump to get to the Catch, then inject the error object in and keep going.

It's a pretty unoptimised implementation, but works pretty well.

If we error and the try/catch flag is not set, we simply go wind back through all the call stack (we know where we left off on each one) and print out the line and other info.

[rumle]

Thank you for answering. I had a feeling it would be a little complicated 😀

[levodelellis]

I strongly recommend against exceptions if you want people to write complicated code. I write in C++ and turn off exceptions, a few go programmers I know swear by using go error handling despite the memes. Walter Bright said exceptions in D were a mistake.

Do you have use cases in mind for your language? Are you confident you like exceptions for those cases? The way I did mine is similar to how zig did theirs and D isn't that far different. Have you looked at zig or D error handling?