Godot: some kind of try finally (or except) block for gdscript

Hmm, for me I prefer crashes in my program over weird behaviors due to bad code. Please, don't take it
wrong, I love exceptions, when they are done right.

I believe this should be left for v2.1 for the new statically (mixed with "dynamic" features maybe?) typed script.

Exceptions won't happen. Godot is designed for things to keep working even
if state is inconsistent, while at the same time reporting errors

On Sat, Jan 30, 2016 at 8:18 AM, RebelliousX [email protected]
wrote:

Hmm, for me I prefer crashes in my program over weird behaviors due to bad
code. Please, don't take it
wrong, I love exceptions, when they are done right.

I believe this should be left for v2.1 for the new statically (mixed with
"dynamic" features maybe?) typed script.

—
Reply to this email directly or view it on GitHub
https://github.com/godotengine/godot/issues/3516#issuecomment-177151923.

is an idea think about it. say for example you have a bunch of images in a folder you wanna open them all up as a tileset but say there are no images nothing should happen. while it may seem like you can simply check for null in the folder your code is actually simpler in a try block TRY to do it if not that's cool. the whole concept of duck code is even more duck code.

plus even python has it try except does the same thing i am proposing so is not unheard of

yes, this was evaluated and considered for a long time, seeing pros vs cons.
exceptions won't be added

On Sat, Jan 30, 2016 at 8:45 AM, trollworkout [email protected]
wrote:

is an idea think about it. say for example you have a bunch of images in a
folder you wanna open them all up as a tileset but say there are no images
nothing should happen. while it may seem like you can simply check for null
in the folder your code is actually simpler in a try block TRY to do it if
not that's cool. the whole concept of duck code is even more duck code.

plus even python has it try except does the same thing i am proposing so
is not unheard of

—
Reply to this email directly or view it on GitHub
https://github.com/godotengine/godot/issues/3516#issuecomment-177155429.

no problem :)

Hasn't ever happened to you that you check if a node's process function if a instance of a node is valid and then it fails because "index not valid for a previous freed instance"?

Since the error is not deterministic and it could immediately make the game crash (and that is annoying, especially because in an exported game that is not reported at all). A try, catch would resolve the bug in an extremely clean and simple way.

Is this still a FIRM no?

@salvob41 in this case you can use this:

if is_instance_valid(object):
    #Do what you want if the node exists

@salvob41 in this case you can use this:

if is_instance_valid(object):
    #Do what you want if the node exists

@Kotzuo, this does not always work, since it is not deterministic the execution flow. the process function is dangerous

@salvob41 in this case you can use this:

if is_instance_valid(object):
    #Do what you want if the node exists

@Kotzuo, this does not always work, since it is not deterministic the execution flow. the process function is dangerous

you are absolutely, 100% correct...... it is a dangerous pattern

in the case of doing network code though, it's brown trousers! the thing can sometimes disconnect between getting the connection status codes!

it's a little tiring in GDScript this defense from other people that don't have (or don't think they have) this problem.... and suggesting to them, maybe other people code with different patterns. Maybe you're coding "right" and my way is "wrong".... i dunno, but i have successfully coded this way for several years and now getting this feature wouldn't force them to use it, but not having it forces me to code like them.

If we got a try and catch statement, no-one has to use it.... people like me and this guy want it as a feature for us to code the way we like to

It's a tough decision. But, since godot does not handle errors very well we can try to wrap every single null/error return into another language which supports error handling the way we want.
Swift is a good alternative:

Error handling in Swift resembles exception handling in other languages, with the use of the try, catch and throw keywords. Unlike exception handling in many languages—including Objective-C—error handling in Swift does not involve unwinding the call stack, a process that can be computationally expensive. As such, the performance characteristics of a throw statement are comparable to those of a return statement.

It should not be a problem if there's a way to use Swift. I'm a beginner in godot, and I've heard there's a way to link another languages dynamically...
Oh, another good news. In 2020 swift will add official support for windows.
I'm a total noob at this subject but there might be a way for us to get error handling without 1 thousand if statements and optional logic flow.

yes, this was evaluated and considered for a long time, seeing pros vs cons.
exceptions won't be added

On Sat, Jan 30, 2016 at 8:45 AM, trollworkout [email protected]
wrote:

is an idea think about it. say for example you have a bunch of images in a
folder you wanna open them all up as a tileset but say there are no images
nothing should happen. while it may seem like you can simply check for null
in the folder your code is actually simpler in a try block TRY to do it if
not that's cool. the whole concept of duck code is even more duck code.
plus even python has it try except does the same thing i am proposing so
is not unheard of
—
Reply to this email directly or view it on GitHub
#3516 (comment).

Well, it's been 4 years since this topic started (and ended), and there are still people who facing this problem (me, for example). I've tried != null, weakrefs, is_instance_valid, it's no use, because the state of the referenced node simply changes between the validity check and the calling for reference's method. Try .. catch (except, whatever) would solve this problem in a sec.

@reduz please reopen this.
I want to handle json so that it doesn't crash the editor when I assign a invalid type.
Godot is not something I would consider stable, it crashes on me daily due to gdscript not being statically typed

@Shadowblitz16 This has already been discussed at length, and it's clear by now that exceptions won't be added to GDScript. If you want to use exceptions, use another language that supports them such as C#.