ABRT for Ruby

[Vít Ondruch]

Dne 10.7.2012 16:12, John5342 napsal(a):
> On Tue, Jul 10, 2012 at 9:29 AM, Vít Ondruch <vondruch at redhat.com> wrote:
>> You are right, you can change the $PROGRAM_NAME. I'll make several points
>> here
>>
>> * Is there some more reliable way how to detect the script name?
>> * What is the use case and how widely is this practice used? Can we ignore
>> this case? Python handler ignores it if I am not mistaken (but we should be
>> better of course ;)
>> * ABRT ignores such failure and it just logs something like "Executable
>> 'foo.rb' doesn't belong to any package" into /var/log/messages.
> 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?

Vit