> eval feels like such a nasty hack to me. Even if Error.pm is internally
> using eval, at least it wouldn't be polluting my code. Java's exception
> handling was the biggest thing I like about it and so trying to use eval
> directly is hard for me to put up with.
I do not feel like we are polluting code by using eval{ }. Perhaps this is
because we do not really consider instance .pl scripts to be "code".
Perhaps it doesn't bother me because I'm comfortable with using eval{ } for
all sorts of things, or perhaps because it is often used in common Perl
solutions (mod_perl, perl_ex, CGI::Carp, Error.pm, ect).
Considering pollution, I might argue that you would be polluting your code
with Error.pm You will be required to use it (correct me when I'm wrong,
please) throughout your code, calling it's methods (or instantiating it's
sub-classes) when an error condition needs to be handled. We have only a
single eval{ } in our entire solution (a minor pollution in comparison IMHO)
and use standard "die( )" calls. Therefore, our die and eval solution will
work with our error handling system, or the eval{ } part could be replaced
with another method (CGI::Carp).
I do not intend to try to convince you that you are wrong ... I'm just
trying to see the logic of considering eval{ } pollution, but Error.pm's
eval-like try to be non-polluting.
Thanks,
Cory Trese
Lead Web Application Developer
O'NEIL & ASSOCIATES, INC.
495 Byers Rd.
Miamisburg, Ohio 45342-3662
Phone: (937) 865-0800 ext. 3038
Fax: (937) 865-5858
E-mail: suppressed
---------------------------------------------------------------------
Web Archive: http://www.mail-archive.com/suppressed/
To unsubscribe, e-mail: suppressed
For additional commands, e-mail: suppressed
Mail converted by mhonarc 2.6.15
This archive provided courtesy of JSW4.NET, Internet Hosting Services for Small Business.