Many internal Mixin errors, particularly InjectionErrors, are raised as the result of invalid mixins (e.g. failed injection check as the mixin was compiled for a different Minecraft version) or mixin conflicts that are not issues in Mixin itself. These MixinErrors don't currently get handled by IMixinErrorHandler handlers, and when propagated to more generic error handling code don't have much machine-readable context.
Wrapping these errors in MixinApplicatorExceptions allows them to be handled by existing IMixinErrorHandler implementations in the apply error phase, and attaching this context allows Mixin callers to reason about the cause of mixin errors and present them in a more user-friendly way.
MixinApplicatorStandard seems like the most appropriate place to insert context of the current mixin and activity stack similarly to the existing Exception handling, and doesn't require MixinError to change how it is constructed and used by internal Mixin code.
Many internal Mixin errors, particularly
InjectionErrors, are raised as the result of invalid mixins (e.g. failed injection check as the mixin was compiled for a different Minecraft version) or mixin conflicts that are not issues in Mixin itself. TheseMixinErrors don't currently get handled byIMixinErrorHandlerhandlers, and when propagated to more generic error handling code don't have much machine-readable context.Wrapping these errors in
MixinApplicatorExceptions allows them to be handled by existingIMixinErrorHandlerimplementations in the apply error phase, and attaching this context allows Mixin callers to reason about the cause of mixin errors and present them in a more user-friendly way.MixinApplicatorStandardseems like the most appropriate place to insert context of the current mixin and activity stack similarly to the existingExceptionhandling, and doesn't requireMixinErrorto change how it is constructed and used by internal Mixin code.