Show quoted text> I cannot really see how you would end-up with calling the reporting functions with an object
> instead of the usual string. Maybe something should be fixed there as well.
Agreed. I can easily fix that, but it was more of a concern that it was
happening and I hadn't noticed (as the normal logging died at that point).
I haven't checked, but I *think* the offending code is similar to this:
https://github.com/ctrlo/GADS/blob/c4cc56584790c0a4b897efd2e918b2c5aa711489/lib/GADS.pm#L85
Show quoted text> We can improve handling a bit for any foreign object which stringifies nicely:
>
> --- lib/Log/Report.pm.old 2017-10-11 22:56:31.562159164 +0200
> +++ lib/Log/Report.pm 2017-10-11 22:57:32.365818738 +0200
> @@ -116,6 +116,11 @@
> elsif($message->isa('Log::Report::Message'))
> { @_==0 or error __x"a message object is reported with more parameters";
> }
> + else
> + { # foreign objects
> + @_%2 and error __x"odd length parameter list with '{msg}'", msg => $message;
> + $message = $lrm->new(_prepend => "$message", @_);
> + }
I think this is sensible, just to handle the situation cleanly in case it happens.
Show quoted text> Also, objects with useful metadata could also be converted cleanly into LR::Message or LR::Exception objects.
> In the specific case of DBIx::Class::Exception, we could extract the location of the error nicely from the
> actual message. I think that code should go into LR::Dispatcher::Try where is also decodes Carp messages.
Yes, now that would be nice :)
Andy
