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

[ghost]

In Python is called try except in Java try catch finally. Run the code inside try block if it fails run the finally block instead. This can greatly simplify coding in gd script by removing all crashes. You will no longer have to worry about bad code. Sometimes you may want to have 1 code working on a dynamic piece of data and not have to build extra failsafes in case say no data is there.

ALL errors from a failed try block will always show up in debug window anyway (automatic catch) so even if you don't have to worry you can still see your code is bad.

try
... code here
finally
... code here

[RebelliousX]

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.

[reduz]

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 notifications@github.com
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
#3516 (comment).

[ghost]

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

[reduz]

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 notifications@github.com
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).

[ghost]

no problem :)

[salvob41]

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?

[hudson-bruno]

@salvob41 in this case you can use this:

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

[salvob41]

@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

[RichardEllicott]

@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

[leo1mml]

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.

[splinefx]

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 notifications@github.com
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.

[Shadowblitz16]

@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

[Calinou]

@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#.

[TheSecurityDev]

Sorry for the bump

I have an error reporter I use for my Rust library, and I want to be able to use it to report any script errors that occur in GDScript. The problem for me is that there is no way to detect script errors. If we can't have try-catch exceptions, then at least add some kind of way to detect when there is an error and what the error is, so we can alert the user that something went wrong and/or report it. I'm aware of NOTIFICATION_CRASH, but it doesn't seem to catch script errors (I can't get it to fire in any case). Maybe there could be a signal or something like NOTIFICATION_SCRIPT_ERROR. If there's any way to do this that I'm not seeing, please let me know.

Also, about exceptions, I have a save and load system that uses JSON data. I want to be able to catch any issues that occur while loading the file (say if the JSON has missing keys or invalid types). I have to manually verify each key and value to make sure it won't cause a crash. I think the saying "it's better to ask for forgiveness than permission" applies here, since it would be much simpler to just catch any error that occurs during the loading, instead of trying to detect and catch all possible errors individually (like check if key exists and value is correct type). Maybe it's bad coding, but I think it's better to let people code how they want.

Another reason to have some kind of exception is because the error might have broken something, so you end up with a situation where you get weird behavior without knowing exactly what caused it. Right now if something goes wrong in an exported, standalone build, there's literally no indication of an error since the engine will continue working normally. We need a way to see if something went wrong during an operation, and stop the operation to prevent further errors.

TL;DR: Exceptions (try-catch or something) would be great, but AT LEAST add a way to detect exceptions (script errors) in exported builds so we can know when they occur and then report them. It's really dumb to not be able to detect errors.

[KnIfER]

@salvob41 in this case you can use this:

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

How do you check the object is a Camera instance ?

[Calinou]

@TheSecurityDev This should be discussed in a proposal, as this issue is closed and this repository is now used for bug reports only. There's already godotengine/godot-proposals#297 which is focused on C#, but it makes sense to have another proposal dedicated to GDScript and GDNative.

How do you check the object is a Camera instance ?

if object is Camera should do the trick. Please ask support questions on other community channels 🙂