-
-
Notifications
You must be signed in to change notification settings - Fork 1
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
NoMethodError: private method 'load' called for nil:NilClass
#10
Comments
private method
load' called for nil:NilClass`private method 'load' called for nil:NilClass
After a second thought this might even be enough: def load_extensions(*extensions, from: Frame.previous.path)
- @loader = Loader.new(self, from) unless loader_defined_before_entrance = defined?(@loader)
+ @loader = Loader.new(self, from) unless loader_defined_before_entrance = !@loader.nil?
@loader.load(*extensions)
ensure
@loader = nil unless loader_defined_before_entrance
end |
@marcoroth thank you for trying out the gem and for the issue! Technically, you shouldn't need to call But if you do, it should still work. I'll look over this because I want to make sure I understand it properly, thank you for the repro, it's very helpful. |
@marcoroth I couldn't figure out how to reconcile the implementation with being able to support manually calling I'll fix the other issue open and prep a new release. |
Thanks @kaspth! I'm wondering if you actually needed to strip out that feature. Maybe a warning or raising an error like "Calling But either way, I appreciate you looking into it! 🙌🏼 |
Hey @kaspth, thanks for creating this awesome gem!
I've encountered a weird issue on the latest 0.3.0 version. I have a minimal reproduction repo here: https://github.com/marcoroth/conventional_extensions-repro
I guess the main questions is: Am I even supposed to use
load_exentions
inside a model class underapp/models/
?Versions
Relevant Files
app/models/post.rb
app/models/post/extensions/mailroom.rb
Reproducion Steps
Possible fix?
This seems to fix it locally, but honestly I haven't fully grokked why
@loader
wouldn't need to be defined in some cases. This "fix" possibly also has some unwanted side-effects since@loader
is not going to be cleaned up in theensure
block because of theloader_defined_before_entrance
condition.I assume the
defined?(...)
is not doing the right thing, it returns a truthy value even if@loader
isnil
and thus not instantiating a loader.Either way, I'm happy to open a pull request if this fix makes sense.
The text was updated successfully, but these errors were encountered: