I agree that using exceptions is a Good Thing, however I think there's
some problems here.
On 30/03/06, Mark Hedges <[EMAIL PROTECTED]> wrote:
>
> I never know what I'm doing wrong. I just get an undefined value
> from methods. Was nothing found? Is the relation broken? Where
> did it break? I do things in eval { } and I get no $EVAL_ERROR.
I don't think a database returning an empty result should throw an
exception, so checking for undef seems reasonable to me.
Adding an option to make an empty result be fatal might be possible, I
certainly wouldn't want it as the default behaviour.
I use DBI's RaiseError setting, so if there's an sql error, it dies.
If there's a broken relation, but it's valid sql and returns an empty
result, how's dbix-class supposed to know the relation is broken?
(I think) most of the errors that could occur are sql, and so are
already thrown by DBI.
I don't think it's dbix-class's job to catch those and rethrow them as
proper Exception objects, if anything, it should be DBI's job to do it
that way in the first place.
In my (limited) experience, most dbix-class specific errors occur
during compilation, and so exception handling is less useful.
Carl
_______________________________________________
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/
