On Sun, May 13, 2007 at 10:25:16PM +0200, Bernhard Graf wrote:
> Documentation tells that DBIx::Class::ResultSet::find() returns a row
> object.
>
> What it does not tell is what is returned if no row is found. Actually
> it returns an empty list in list context - not an undef as one might
> expect.
find() returns -nothing- if nothing is found, not an undef which corresponds
to SQL NULL.
> While the difference between empty list and undef is usually not
> important, it can lead to confusing results if find() is called as
> subroutine argument:
>
> do_something($alpha, $rs->find($id), $omega);
>
> meaning do_something() is called with three arguments if find() succeeds
> and two arguments if it fails.
I always do
if (my $obj = $rs->find(...)) {
for clarity.
> So since find() is not designed to return lists, to be consistent it
> should always return a single value: either a row object or undef.
Depends really - is it worth giving up consistency to support the poor
programming practice exemplified above?
Opinions welcome, I'm not -overly- troubled either way although by default
I'd say the current conceptual consistency is the correct answer.
--
Matt S Trout Need help with your Catalyst or DBIx::Class project?
Technical Director Want a managed development or deployment platform?
Shadowcat Systems Ltd. Contact mst (at) shadowcatsystems.co.uk for a quote
http://chainsawblues.vox.com/ http://www.shadowcatsystems.co.uk/
_______________________________________________
List: http://lists.rawmode.org/cgi-bin/mailman/listinfo/dbix-class
Wiki: http://dbix-class.shadowcatsystems.co.uk/
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/trunk/DBIx-Class/
Searchable Archive: http://www.mail-archive.com/[email protected]/
