hugeblank / allium

Lua script loader and API for easy Minecraft modding
MIT License
41 stars 8 forks source link

More Useful Errors, Consistent Error Handling #39

Open hugeblank opened 1 year ago

hugeblank commented 1 year ago

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.