Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

More Useful Errors, Consistent Error Handling #39

Open
hugeblank opened this issue Apr 2, 2023 · 0 comments
Open

More Useful Errors, Consistent Error Handling #39

hugeblank opened this issue Apr 2, 2023 · 0 comments
Labels
enhancement New feature or request

Comments

@hugeblank
Copy link
Member

I've had my fair share of crashes when working on mods in Allium. Generally it's been an issue with Allium logic that I've been able to work out, but sometimes it's an issue with Lua code. The errors on that front are a little less descriptive and consistent than I'd desire:

Lua compile error - does not crash game.
Lua runtime error - crashes the game.
Lua runtime error in event - does not crash game.

What's our goal? Do we want to minimize crashing if possible? Or should we just let the game crash just like how the situation would be handled in java? I'm leaning more towards the latter, since pretty regularly I'll have an event registered per-tick or per-frame which spams the log until I pause/terminate the game myself. Additionally I have a feeling that with pcall the lua user might be able to control crashing which I would be much more in favor of.

As for specific errors that I think we could expand on:

Type mismatch errors are probably the most common, and while they give a descriptive output of what types the input parameters can be for any given method, they don't provide the types that were input by the user. I think this enhancement alone could substantially improve debugging for a user. Generally the fix is just changing a dot to a colon to pass the userdata along.

Another error I think we could look into providing more details on is a fun one. When there's a public method and a field with the same name (World.isClient), the method is selected first. This is seldom an issue but when it is it's a doozy to figure out. Fortunately when there is such an issue the method returns the field value, but I can imagine some really dumb situations where that's not the case. I bet there's some fiddling we could do with __index, PropertyResolver and UserdataFactory to resolve a name like .f_name to a field name that shares a method name. There's probably a better way of going about fixing this though which I'll leave open for discussion here.

@hugeblank hugeblank added the enhancement New feature or request label Apr 2, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant