Dependencies shouldn't swallow errors from required files.
Reported by Marcel Molina | May 1st, 2008 @ 09:08 PM | in 2.1.1
What I did:
I, unknowingly, invoked alias_method in a controller incorrectly by supplying the arguments in the wrong order.
What should have happened:
Usually this would raise an exception saying something like "No such method defined `whatever_your_alias_is_called'".
What happened:
When I ran my tests though, before I'd realized I'd invoked alias_method with the arguments in the wrong order, the exception I was greeted with was:
"Expected foos_controller.rb to defined FoosController". In this case foos_controller.rb does in fact define FoosController, so the exception is entirely misleading.
To find out the actual exception, I added an initializer that required 'application' and then 'foos_controller' to circumvent const_missing auto loading. Then the actual proper exception was raised.
Versions effected:
This behavior is both in 2.0.2 and in edge.
Comments and changes to this ticket
-
-
Michael Koziarski May 1st, 2008 @ 10:27 PM
- → Milestone changed from “” to “2.1.1”
- → Title changed from “Incorrect alias_method call in controller causes misleading const_missing exception” to “Dependencies shouldn't swallow errors from required files.”
- → Assigned user changed from “” to “Michael Koziarski”
This is frustrating as it masks the true error. I get similar behaviour when I use my 'apple ruby' which doesn't have rmagick installed.
Dependencies shouldn't drop the load error on the ground, it should at the very least show what the original error was, if not raise the original exception
-
Roger May 2nd, 2008 @ 02:28 AM
+1 for wishing this didn't occur. Some work has been done on
http://dev.rubyonrails.org/ticke...
for it [though nothing really satisfactory].
-
Tom Ward May 23rd, 2008 @ 03:54 PM
I've only found one way to reproduce this; In production mode, if an error occurs on the first require of a file, on subsequent requires the error will mask the real problem. I've created a patch that fixes this, but there may well be other ways to make this occur.
If anyone has any other reproducible examples, I'm happy to take a look.
-
Roger May 23rd, 2008 @ 06:01 PM
I believe it happened to me if there was an error in a plugin loading. Like a syntax error in one of the files. The 'real' error message was never output.
In one instance, it was because the plugin filename didn't use rails'ish style syntax [was name acts-as-something instead of acts_as_something]. I'll let you know if I run into it again.
-R
-
Tom Ward May 23rd, 2008 @ 06:10 PM
That specific problem (the plugin-with-hyphenated-name) loading issue was fixed in #24. I got tripped up by that too.
-
Repository May 31st, 2008 @ 09:35 PM
- → State changed from “new” to “resolved”
(from [77e45352e7e947f1df1bfb8fe7d9e4e133224dd9]) Fixed Dependencies so load errors are not masked behind a 'Expected x.rb to define X' message when mechanism is not set to :load [#87 state:resolved]
Signed-off-by: Joshua Peek
Please Login or create a free account to add a new comment.
You can update this ticket by sending an email to from your email client. (help)
Create your profile
Help contribute to this project by taking a few moments to create your personal profile. Create your profile »
Source available from github
The Git repository resides at http://github.com/rails
Check out the current development trunk (Edge Rails) with:
git clone git://github.com/rails/rails.git
Creating or reviewing a patch
See the contributor guide.
Creating a feature request
Please don't. If you want a new feature in Rails, you'll have to pull up your sleeves and get busy yourself. Or convince someone else to do it. See the contributor guide on how to get going. But posting them here is just going to lead to ticket root.
Creating a bug report
When creating a bug report, be sure to include as much relevant information as possible. Post the code sample that causes the problem. Preferably, alter the unit tests and show through either changed or added tests how the expected behavior is not occuring.
Security vulnerabilities should be reported via an email to security@rubyonrails.org, do not use trac for reporting security vulnerabilities. All content in trac is publicly available as soon as it is posted.
Then don't get your hopes up. Unless you have a "Code Red, Mission Critical, The World is Coming to an End" kinda bug, you're creating this ticket in the hope that others with the same problem will be able to collaborate with you on solving it. Do not expect that the ticket automatically will see any activity or that others will jump to fix it. Creating a ticket like this is mostly to help yourself start on the path of fixing the problem and for others to sign on to with a "I'm having this problem too".
Renaud Morvan