On Jun 12, 2010, at 8:23 AM, Bill Moseley wrote:
On Fri, Jun 11, 2010 at 8:41 AM, Karen Etheridge <p...@froods.org>
wrote:
On Fri, Jun 11, 2010 at 07:37:27AM -0700, Bill Moseley wrote:
Our developers (and people that handle staging) have been
remarking about
very low signal to noise error messages since moving some of our
code to
Moose.
Unless you're doing a lot of runtime role application or other meta
magic,
virtually all the errors you should be seeing from Moose happen at
compile
time during development, so I would expect you would be screening
these
out before you get to staging. Is this not your experience?
As I said, my bet is that the error I posted is a dependency issue --
haven't had time to resolve yet.
It is, you have an old copy of MooseX::AttributeHelpers on the prod
box, upgrade it and this will go away.
So, in this case it compiles and runs fine on the development box.
But,
when the QA team pushed to their hardware they got that error --
which they
had no idea how to decipher.
The QA team needs to make sure they have the same versions as the
development box, this is a deployment issue really.
The rule for reading stack traces is to look at the top and then move
down. While it is true that the true problem is usually the very top,
often times I find that being able to see the deeper calling context
going back up the call stack is very helpful.
This particular error is difficult to decipher largely because it is
an error between Moose and an old version of MooseX::AttributeHelpers,
neither of which are your code, so therefore difficult for you to
decipher at first glance.
Perhaps unfortunate, but the dev box probably happened to have the
required
libraries so Makefile.PL was not updated with new dependencies which
would
have prevented this.
Exactly.
But, my question here was more about making these message more
concise in
general. True, with a bit of practice the developers can usually
find the
important bits at the top of the trace.
What exactly would conciseness buy you?
I find that the more information I have at the start of a bug hunt the
quicker I can find the source and fix it.
Sure some Moose error messages could be less cryptic, but then we run
into the difficulty of divining user intent from user action, I
believe there was a long discussion on this previously on the list.
- Stevan
