Dne 10.7.2012 17:06, John5342 napsal(a):
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.
Right. I will keep it simple for now, report it to the entry point
application. Thinking about gems would definitely add more fragility
than anything else.
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).
This could be done. The python handler for example adds values of local
variables as a bonus. This might be also very valuable information. Will
try to keep that idea in mind, if I'll get bored ;)
Vit