Dne 10.7.2012 17:06, John5342 napsal(a):
On Tue, Jul 10, 2012 at 3:27 PM, Vít Ondruch <[email protected]> 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
_______________________________________________
ruby-sig mailing list
[email protected]
https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
