I see both sides to this tangential issue.

Yes, eval { die} is little more than a pretty skin on C's
setjmp/longjmp. But Perl was originally 'just' a pretty skin on libc,
with a read-eval-print loop and a regex lib added. This is not in itself
a bad thing, it's a solid foundation and often hurts less than using
libc from C. This is especially true with longjmp !

eval { die} is usable *with an adequately documented idiom* to do
exception handling, in the spirit of TIMTOWTDI. But it is not a fully
developed, one-size-fits-all, mandatory type-checked restrictive
exception system as a Ada / Java programmer would recognize and expect.
(Or Python?)

With a choice of the CPAN Exception classes, one can build upon that to
create, not the One True Exception mechanism, but the one you want.
(  http://search.cpan.org/dist/exception/ and/or one of
http://search.cpan.org/dist/try/  ) 

Yes, integrating multiple exception-using packages in an application
means one has to rethrow what one doesn't want. It's the fisherman's
rule, throw back what you catch but can't eat. The good news is that
Perl's flexible typing means one can check if the item caught is a
string or ref, blessed or not, of type desired or not, CAN do method
you'd like to ask of it or not, all without a universal Exception parent
class built into the language type hierarchy.  This may be explicit in a
rethrow unknown idiom (whether OO ISA or regex against stringized value,
however expressed syntactically, ugly if-chain or elegant Switch.pm or
p6/5.10 given/when) or may be built into an Exception module's catch,
which gives syntactic sugar and the appearance of typed catch. 

Yes, strongly typed OO languages know too much about their libraries;
this is why people are slowly returning to role-based signatures (obj1
CAN do_x , not obj1 ISA class_y ). Smalltalk got it almost right the
first time; it lacked syntactic sugar for expressing the CAN guarantees
and requirements. 'We' (the larger community) over-simplified when 'we'
merged C, SmallTalk, and Ada/Modula into C++ and Java by conflating ISA
and CAN, inheritance of interface (CAN) and inheritance of
implementation (HAS, and how). Those of us who preferred Objective-C are
not surprised that this was wrong.  (And we few ST&Obj~C veterans in the
Perl community are not surprised that Merlyn's other consulting language
is SmallTalk. The two communities have more in common than either
realizes, much more than is apparent from the radically different syntax
and semantics ... Which gap will narrow appreciably with P6.)

-- Bill @ $DayJob
 not speaking for the firm

Boston-pm mailing list

Reply via email to