Raise an error for script.get_event_handler(invalid_event_number)

[eradicator]

What?

LuaBootstrap usually raises an error for script.on_event or script.get_event_handler if the given event_name is invalid, except get_event_handler() if the event_name is a number.

Code: Select all

/c game.print(type(script.get_event_handler(99999)))

invalidevent.png (562.06 KiB) Viewed 2785 times

Why?

Debugging and given better feedback to users of my library. Having something like script.is_valid_event_name() would be much better, but i doubt chances are very good for that?

[Rseding91]

My thought process is: if there are multiple same-type functions each only valid during specific situations then they give errors when invalid. For example: LuaItemStack and accessing functions for specific item types (blueprints, deconstruction planner, upgrade item and so on). They each throw if the item isn't that exact type.

If there's only 1 function and the option is: return nil when wrong vs throw when wrong + add a is-right function. The extra overhead of the "is-right" function being required to use the other function is just wasted time on everyone's part.

So; with all that - I don't see the utility in having it error on a unset value. All it would do is make you call another function first to avoid the error. In the end code isn't better because of it.

[eradicator]

return nil when wrong

Thanks for the detailed answer. The problem i'm having is that "nil" is not distinctly "wrong" because it can also mean that there simply is no handler registered for a valid event name.

return nil when wrong

Also it does throw an error for wrong custom inputs. So there's two possible outcomes for "wrong": error or nil.


So my thought process is: As far as i can tell there currently is no direct way to determine if any given integer is a valid event name or not. I always need an extra function call if i don't want users of my library to recieve cryptic error messages with stacktraces deep into the library. And with the current state of things the only method available is pcalling script.on_event because there is no is_valid_name and pcalling script.get_event_handler does not reliably error.

[eradicator]

I took a walk and got some fresh air, and while I had an idea how I might be able to solve my current problem I noticed that there is another group of problems:

If a mod implements a new event, i.e. "on_entity_teleported" and uses script.generate_event_name() to create a unique id... and then the mod requires me to use it's remote interface to retrieve that id so I can subscribe to the event... then again the only way to not crash my mod when then remote gives me a garbage id is pcall()'ing script.on_event.

[Rseding91]

I took a walk and got some fresh air, and while I had an idea how I might be able to solve my current problem I noticed that there is another group of problems:

If a mod implements a new event, i.e. "on_entity_teleported" and uses script.generate_event_name() to create a unique id... and then the mod requires me to use it's remote interface to retrieve that id so I can subscribe to the event... then again the only way to not crash my mod when then remote gives me a garbage id is pcall()'ing script.on_event.

Crashing due to other mods giving you garbage isn't your concern. The other mod should not be giving garbage.

[eradicator]

Crashing due to other mods giving you garbage isn't your concern. The other mod should not be giving garbage.

As far as i recall the whole limitation of script.raise_event to only allow raising a limited subset of events with verified data was exactly to solve the "other bugged mods are crashing my mod" problem. And that was a much larger change. Also i don't get to chose what is "my concern" when users complain that the error message says my mod crashed.

[Rseding91]

Crashing due to other mods giving you garbage isn't your concern. The other mod should not be giving garbage.

As far as i recall the whole limitation of script.raise_event to only allow raising a limited subset of events with verified data was exactly to solve the "other bugged mods are crashing my mod" problem. And that was a much larger change. Also i don't get to chose what is "my concern" when users complain that the error message says my mod crashed.

The primary reason for it was to enforce that event filters worked correctly when events were raised and to enforce that mods couldn't pass garbage to standard events.

When someone does raise_event and it errors on the raised event side the mod calling raise_event gets blamed for the error.

[eradicator]

So why does script.get_event_handler() raise an error for invalid custom input string names but not for numbers?

[Rseding91]

So why does script.get_event_handler() raise an error for invalid custom input string names but not for numbers?

The set of custom inputs is known at game start and never changes runtime. That means any mod should know and should never need to guess if a custom input name they want to get is valid or not.

Runtime event handlers (from generate_event) are not known except by just checking to see if at the time of running the given event ID is valid.

[eradicator]

The set of custom inputs is known at game start and never changes runtime.

Right, game.custom_input_prototypes exists. That makes sense then.

Runtime event handlers (from generate_event) are not known except by just checking to see if at the time of running the given event ID is valid.

Except there is no way to check that from a mods perspective. That's kinda the point of this whole thread.

[raiguard]

Runtime event handlers (from generate_event) are not known except by just checking to see if at the time of running the given event ID is valid.

Except there is no way to check that from a mods perspective. That's kinda the point of this whole thread.

Actually, you can check if an event ID exists by pcalling script.on_event and seeing if pcall returns an error, then immediately deregistering the event again. It's horrible, but it works.

[eradicator]

Runtime event handlers (from generate_event) are not known except by just checking to see if at the time of running the given event ID is valid.

Except there is no way to check that from a mods perspective. That's kinda the point of this whole thread.

Actually, you can check if an event ID exists by pcalling script.on_event and seeing if pcall returns an error, then immediately deregistering the event again. It's horrible, but it works.

That is not desync safe. Also avoiding pcall was the main point of this request. I've remodeled my code to fix the original issue, but the whole "other mod is giving me garbage" problem remains.