That's not all Error has to offer though. I use it, so far trying and catching nearly only in tests. I might use try/catch in the future, but so far the implementation of it as an exception object has been pretty useful without the error handling per se.

The reason I like exception objects is that they promote machine recognizable errors, and thus make error handling/reporting easier.

Firstly, each error has a class. You can represent groups of errors rather easily with inheritence.

A certain type of error could inherit from the pseudoclass Error::Recoverable, for example, to allow code catching it to re-attempt the errorneus code. Error categories, for the sake of clean reporting are also nice.

Another feature of error objects is that they are compound. In my errors, the string is just for the user. I have a unique code for each error (generated by a constant allocator). This is more deterministic than matching regexes on error strings.

Now, with all this, and the fact that Error is still outwardly compatible with string errors, since the objects stringify, I see no reason why not to promote at least partial use of the Error module.

I would suggest autarch's Exception::Class for easy creation of exception classes / objects.

Just to note: you can throw an error object with die. You can throw anything with die.

eval {
     die new MyException("foo");
};

if (UNIVERSAL::isa($@, 'MyException') {
     print "Then my example worked!"
}
[download]

Ted Young

($$<<$$=>$$<=>$$<=$$>>$$) always returns 1. :-)

That's exactly what I mean. =)

But don't use UNIVERSAL::isa, that makes overridding ->isa hard.

-nuffin
zz zZ Z Z #!perl