Runtime Error Limitations (additional toggle)

[lafless]

Suggestion

I would like to suggest the addition of runtime toggles. While I understand the benefits of Addons making use of runtime errors, some use cases pose a risk to unnecessary spam and confusion to both entry-level and experienced Skripters.

Why?

Many entry level Skripters tend to not understand the logic behind null values, which is where runtime errors come into play. I think it's important for Skript's coding language to mimic Java's error handling, ex; requiring null checks before checking NBT data (SkBee). For more advanced Skripters, we run the risk of spam in consoles and in the game chats all due to limitations within Skript's error handling.

Skript currently contains many options for runtime errors, such as frame durations, size of each frame, etc. But it lacks total removal. Whether this is incorporated based on runtime types (which I believe could be a great addition) or just a global Enabled / Disabled option for the time being, I think giving experienced users the ability to disable them would be very beneficial. If this is something Skript will consider adding, I highly recommend adding runtime types, or categories, to further allow experienced users receive select runtime errors based on their coding environment / needs.

Other

Thanks for reading! I would love feedback and maybe other views on how this idea could be expanded upon, or if there is a better alternative.

Agreement

• I have read the guidelines above and affirm I am following them with this suggestion.

[ShaneBeee]

I 100% support the addition of runtime error toggles.

[Sparky200]

My thoughts based on a conversation in the development channel:

• General disinterest in "normal" runtime errors expected from other programming languages
  • By "normal" this means avoiding a lot of the common ones like null errors, unless there's a really fatal reason
  • i.e. if string tag "blah" of nbt of player is "something": - false if player is null, the nbt compound is null, or the tag is not present. No runtime errors in a scenario like that
• If error silencing is desired, it should probably not be global (on a structure level or something instead)
  • Motive here is that when the developer starts writing a lot of new code at once, they have something catching the small but severe things still.
• API should provide more than just error (i.e. warning("Player did not have any NBT"))
  • Error/warnings should be distinguished. The former should mean "oh, something went quite wrong and we shouldn't continue executing" and the latter should mean "oh, here's a strange edge case that you should know happened and would be good to add validation around"

It's probably obvious but my main fear is that operating on bad data or in failed states will be encouraged. and I think there should be reasoning made on what should warrant an error versus allowing something like null propagation (essentially what that first example is doing). You sort of have to compromise between making the language forgiving to users while not pretending they didn't just possibly crash some SQL database or something crazy 😂

[sovdeeth]

The plan was always to implement suppression and toggles for types of errors/warnings, the original PR mentioned that, so don't worry! It didn't come with the initial runtime PR due to it needing a more significant API addition that would probably delay having any runtime errors at all. We need to first implement some method of classification of warnings/errors and a uniform way to suppress them, and that's been one of our goals for 2.11.

[ShaneBeee]

and that's been one of our goals for 2.11.

So Skripters have to wait 6 months for this to be implemented?
Why are half assed things be implemented into Skript without proper thought?

As of right now SkriptLang's extremely poor attempt at a "Clockwork release cycle" is only hindering Skripters because the team is allowing these systems being implemented with extremely low feedback.

This is a community project, but day in and day out its seeming more like SkriptLang only cares about SkriptLang and not its users.

[Moderocky]

Please calm down. 2.11 is releasing in April.

[ShaneBeee]

Please calm down. 2.11 is releasing in April.

with all due respect, how would anyone know this?
As per the clockwork release model, the next release is scheduled for July?
But no one would know anything as per all your guy's private conversations.

EDIT:
A team member (no names) just DM'd me to tell me they didnt know about this either (re: release in April).
If your team doesn't know about it, how should the public?

[sovdeeth]

and that's been one of our goals for 2.11.

So Skripters have to wait 6 months for this to be implemented? Why are half assed things be implemented into Skript without proper thought?

As of right now SkriptLang's extremely poor attempt at a "Clockwork release cycle" is only hindering Skripters because the team is allowing these systems being implemented with extremely low feedback.

This is a community project, but day in and day out its seeming more like SkriptLang only cares about SkriptLang and not its users.

The basics of runtime errors were implemented in 2.10 in order to provide a base to experiment with. The intention is, as you mentioned, to get feedback! Additional features were always meant to come in a later update, once the annotation PR was added.

No runtime errors have been added yet, since given the current inability to suppress them, we wanted to only use them where there wasn't any other good option (see recipe pr and similar situations).

As Kenzie mentioned, we are in the process of updating the release cycle precisely because of that 6 month delay, and we've been implementing more features that allow us to release things more frequently (see experimental feature toggles so features can be released in patches). I'd ask you to be a little less aggressive in the future, it doesn't really benefit anyone.