Perl should definetly die with Can't locate object method "del_attr" via package ...

I'm fine with dying if throwing exceptions is the documented error handling methodology and is used consistently.

Sort of¹. . .

As far as the "definetly" [sic] part of that statement... well, why?

Gracefully handling the error isn't such a bad thing is it? Why throw an exception and force² your user to handle it when you could move on silently and leave no harm done?

I do think that the module's clients should have access to the error if desired. For example, an object can set an error condition and make details accessible via an error() method. Providing that, along with the is_start_tag() method, could give Ovid's module's clients the ability to ask "should I do this?" as well as "did I do what I expected?" And, really, that should be enough.

I understand that from an OO purist perspective, what I'm suggesting is blasphemous. It's lackadaisical, slackish, and lacking the rigor that OO is supposed to enforce. But hey, if you really wanted that, you could shackle yourself to Java or C++ or what-have-you.

I don't want to give the wrong impression. I'm all for rigor, particularly in large projects. But, for a general module which is likely to be used in far more small projects than large ones, I'm not convinced enforcing rigor is the right way to go.

1. I really hate using eval and checking $@. I think it's ugly. But that's a personal issue.

2. And this is the real reason I hate using die() for error handling. It requires that the module's clients use eval, even in cases where it doesn't matter. If you provide another way of handling those cases, then you are in the precarious position of maintaining two separate error handling methodologies, so it isn't a realistic option.

-sauoq
"My two cents aren't worth a dime.";