On Tue, Jul 10, 2012 at 3:27 PM, Vít Ondruch <vondruch(a)redhat.com> wrote:
Dne 10.7.2012 16:12, John5342 napsal(a):
> If the Ruby documentation is to be believed you could use
> Kernel#caller to get a stack trace which apparently has a set format
> including the file name. It is of course swapping a user modifiable
> value for something slightly more fragile (it could potentially change
> in some future version). Perhaps use the current way and fall back to
> Kernel#caller if $0 doesn't resolve to a real file (which would
> indicate it has been modified.
>
> None of this of course covers scenarios where user/other code is
> loaded from within another program (think rake, thor, etc) but in the
> case of an exception, Exception#backtrace is the same format as
> Kernel#caller.
>
John, thank you. Use of the Exception#backtrace is nice idea! Have to take a
look into.
It might be even possible to extract the "latest gem" in the backtrace and
assign the bug to it, but I am not sure if that is good idea, since the
error might be in the gem as well as in its caller. In that case, I would
expect that the library consumer/application author has "more" knowledge
about the library then the library author about the consumer/application.
Thoughts?
Yeah i think you are right there. The entry point is the only
guaranteed thing. The more you narrow things down from there the more
work is needed to avoid getting things wrong so it really depends on
how much effort you want to put into it.
Certainly if i was maintaining a ruby program i would not mind
receiving bugs that are in the end caused by a library used by my
program. I would easily be able to forward it on plus if i have had a
bug then i can watch for the fix etc. Bonus points though if the
report could include a complete list of loaded gems/packages (to help
in ruling out monkey patching issues and the like) and the list of
gems/packages in the call stack at the time of the error (would make
it much easier to see where the problems _could_ be).
--
There are 10 kinds of people in the world: Those who understand binary
and those who don't...