What do people think parsers should return if they can't parse? And what if they do parse, but DateTime doesn't want to create an object of the appropriate specification?
Should we wrap our methods in evals and return undef?
Should we just throw errors?
At 1:06 AM -0500 16/7/03, Dave Rolsky replied:
I'm a big fan of throwing errors, since it forces the callers to actually handle them. Just returning undef leads to this:
my $dt = $parser->parse('this is not a date');
do_something_with_date($dt);
and then mysterious failures later on.
I'm an anti-fan of die. Die requires wrapping in eval or parsing the user's input before passing to ->parse_datetime, which is just crazy.
We should only throw errors on programmer error. For example:
$dt->set( weekday => 'Friday' );
should error because there's no 'weekday' parameter for set().However, we should return DateTime::Undef on user error:
$dt->set( day => 'Twenty-two' );
because it means that we can now test for DateTime::Undef, letting set() do the parsing of the user's input.
Just another $0.02
Cheers! Rick
--
--------------------------------------------------------
There are 10 kinds of people:
those that understand binary, and those that don't.
--------------------------------------------------------
The day Microsoft makes something that doesn't suck
is the day they start selling vacuum cleaners
--------------------------------------------------------
"Write a wise proverb and your name will live forever."
-- Anonymous
--------------------------------------------------------
