Statically loading `Sheets` before NeoForge's registries have been
finalized, often caused by referencing `Sheets` (or a class that
references `Sheets`) statically in an `EventBusSubscriber` prevents
modded `WoodType` added via `Sheets::addWoodType` from being properly
registered.
This results in `getSignMaterial` and `getHangingSignMaterial` to return
null for these types.
Further complicating this is the fact that instances which use this
`Material` (such as in `GuiSignRenderer::renderToTexture`) often use
function references to determine the render type.
Compiled, this transforms the section into a synthetic lambda and
results in unclear NullPointerExceptions that reference the parameters
of the lambda (`$$3`, for example) rather than a clear dereference
indicating that the `Material` is null.
Currently, `Sheets` contains a warning message which is displayed
whenever it is statically loaded before registries have been loaded (and
the mod loader isn't in an error state), but it is possible to miss
this.
Throwing an exception at this point would potentially result in further
confusion.
This patch solves that confusion by storing statically storing the
exception and then re-throwing it the first time `getSignMaterial` or
`getHangingSignMaterial` is called.
While this results in an `IllegalStateException` rather than the current
`NullPointerException`, the relevant stack trace more accurately shows
the actual cause of the issue rather than the unclear error with the
synthetic lambda.
Statically loading
Sheetsbefore NeoForge's registries have been finalized, often caused by referencingSheets(or a class that referencesSheets) statically in anEventBusSubscriberprevents moddedWoodTypeadded viaSheets::addWoodTypefrom being properly registered.This results in
getSignMaterialandgetHangingSignMaterialto return null for these types.Further complicating this is the fact that instances which use this
Material(such as inGuiSignRenderer::renderToTexture) often use function references to determine the render type.Compiled, this transforms the section into a synthetic lambda and results in unclear NullPointerExceptions that reference the parameters of the lambda (
$$3, for example) rather than a clear dereference indicating that theMaterialis null such as (1.21.1 example):Currently,
Sheetscontains a warning message which is displayed whenever it is statically loaded before registries have been loaded (and the mod loader isn't in an error state), but it is possible to miss this as it generally occurs during mod loading and a large amount of data is written to the log at this point.Based on discussions with XFactHD, throwing an exception at this point would result in further confusion, although the new error screen may resolve that.
This patch solves that confusion by storing statically storing the exception and then re-throwing it the first time
getSignMaterialorgetHangingSignMaterialis called.While this results in an
IllegalStateExceptionrather than the currentNullPointerException, the relevant stack trace more accurately shows the actual cause of the issue rather than the unclear error with the synthetic lambda.I'm uncertain how possible it would be to create a test mod for this.
Relevant issue: MysticMods/Roots#1214