Maybe instead of tracing the paths in Perl, you want to make the database do the work instead?

I suggest you either write a view or a query in DBIx::Class that does the JOIN query directly instead of manually fetching the tables from the database.

If you often need to chase multiple levels of tabels, it means you are working on a too low level.

Add an accessor to the result class that does an in-database join over the levels, which automatically deals with the case of not having results at one level or another.

Well, even for one level it is necessary to check first. here's real world example:

my $avatar = $usr->person->avatar;

usr and person (extended information about user) are two tables. not every user has to have extended information and the code snipped just wants to find out if user has avatar.

Adding accessor to usr sounds like a wise solution to hide test ifs, but it will mask the fact that avatar is accessor of person.

Adding accessor to usr sounds like a wise solution to hide test ifs, but it will mask the fact that avatar is accessor of person.

Hiding unneeded facts is what abstraction is all about. Why should a user of your backend model care about which table the avatar comes from? If the user doesn't have to care, it means you can change that stuff later on the in the database and only adapt your model, not your code that generates the HTML.

Perl 6 - the future is here, just unevenly distributed

Perhaps something like:

use feature ":5.14";
use warnings FATAL => qw(all);
use strict;
use Data::Dump qw(dump pp);
use Test::More qw(no_plan);

sub deref(@)
 {my $h = shift;
  for(@_)
   {return undef unless $h and ref($h) eq __PACKAGE__ and $h->can($_);
    $h = $h->$_;
   }
  $h
 }

my $h = bless {a=>bless{a=>bless{a=>bless{a=>1, b=>2}}}};

sub aaa() {$_[0]->{a}}
sub bbb() {$_[0]->{b}}

ok !defined($h->deref(qw(bbb bbb bbb bbb)));
ok 1 == $h->deref(qw(aaa aaa aaa aaa));
ok 2 == $h->deref(qw(aaa aaa aaa bbb));
[download]

Produces

ok 1
ok 2
ok 3
1..3

use strict; 
use warnings; 

#set up a pretend subref inside some other stuff
my $bar = {foo => [ sub {print "fishcake"}]};

{
   no warnings "uninitialized"; # we're going to be a bit naughty in t
+his block
   ($bar->{potato}->[0] or sub {return undef})->() 
}


# swap this for
# ($bar->{foo}->[0] or sub {return undef})->()
# and see what happens
[download]

if you use that then if I were you I'd comment it liberally, and possibly surround it with bio-hazard marker tape.

Even though it may sound very pedantic and old-fashioned, I aggressively write code that verifies that something which might legitimately be undef is or is not.   Then, I enclose blocks of code in exception-handling blocks which, if they go off, package the exception message in another, case-specific class of exception object and then throw that.   I don’t use “well, an exception has been thrown, so eat the exception and then do this,” because an exception could be thrown for any reason, not just the one I expect.

I would politely argue that you should never write that “merely ‘works’ (sic).”   Because there is only one agent out there with a clear chance to determine whether the app is or is not working properly, and that agent is:   the application itself.

The next argument is in favor of clarity above all other considerations.   Go ahead and write two, three, four statements instead of one “clever” one if the multiple-statements approach is “obvious at a glance” and/or more maintainable in the decades to come.   You probably have CPU-power to burn.   (Maybe you legitimately don’t in high-science, but in bread and butter business apps you certainly do ... and what you can’t afford is risk.   Especially the risk of undetected application failure.)