Re^2: the try/catch example from "Programming Perl" analyzed

Don't use ref - use blessed. Now, you can be guaranteed it's an exception object, insofar as you can guarantee that all code you would want to call in an eval/$@ block would propagate exception objects if they propagate objects at all.

------
We are the carpenters and bricklayers of the Information Age.

Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

I shouldn't have to say this, but any code, unless otherwise stated, is untested

Comment on Re^2: the try/catch example from "Programming Perl" analyzed

Replies are listed 'Best First'.
Re^3: the try/catch example from "Programming Perl" analyzed by hardburn (Abbot) on Aug 18, 2004 at 18:11 UTC
Well, that helps a bit with the implementation, but doesn't solve the fundamental problem of having to handle the non-blessed case. Also, you now have to pull in another module to check for blessedness. "There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.	[reply]
Re^4: the try/catch example from "Programming Perl" analyzed by rsteinke (Scribe) on Aug 19, 2004 at 06:15 UTC
You could always use some sort of object wrapper to convert the strings into error objects, and hide that in the 'try' code, `local $_ = (blessed $@) ? $@ : MyStringErrorClass->new($@);` [download] or some such. That class (or a function that returns different error objects depending on the error string, or something), would know all about the Errno module, and other standard kinds of errors. Ron Steinke <rsteinke@w-link.net>	[reply] [d/l]


Come for the quick hacks, stay for the epiphanies.
	PerlMonks