Bradley Baetz wrote:
> Right, but see my first method - I can't differentiate between the
> various errors.
OK, I see the problem now.
> at the end. Will a match on /: not found$/ always match a file not found
> error, and nothing else? And will this message avoid changing in the
> future for some reason?
Yes, probably, but no, I wouldn't rely on it.
I've just made a change (in CVS, developer release following soon) which
has the provider return a parse exception (rather than a string), which the
context template() method then re-throws as a file exception. The original
exception is passed as the info part of the new exception, so you end up
with something like this:
{
type => 'file',
info => {
type => 'parse',
info => 'blah.html line 99: some error message',
}
}
This seems like a more correct behaviour, to effectively nest exceptions
as they get thrown up.
Now you can reliably (if slightly long-windedly) test it like so:
eval {
my $file = $tt->context->template('foobar.html');
};
if ($@) {
my $error = $@;
my ($type, $info) = $error->type_info();
if ($type eq 'file' && ref $info && $info->type() eq 'parse') {
print "parse error, dude: ", $info->info(), "\n";
}
else {
print "regular error, fella: $info\n";
}
}
The auto-stringification of exceptions should mean that you can still
print $exception->info() and it will Do The Right Thing, even if the
info is a nested exception.
HTH
A
_______________________________________________
templates mailing list
[EMAIL PROTECTED]
http://lists.template-toolkit.org/mailman/listinfo/templates
