Thanks for the link - interesting reading. The whole raison d'etre for my original post was that though I philosophically fall into the same camp, I have problems with the implementation/execution - in the absence of true built-in Exception handling, I have to decide between a couple of options: either fake up a try/catch type of thing by using eval {...}; if($@){...} or go with the old return undefined and let the caller inspect the object's error() method.
| [reply]
[d/l] |
| [reply] |
Well, I guess it's a matter of defining what we mean. My definition would be that when code does something exceptional i.e. contrary to the "normal" flow or producing an unwanted error condition, the interpreter will interrupt program flow by propagating an object that encapsulates the error information, up through the stack until it finds code ready to handle it. The key here is that while die within an eval{} sets $@, that is an error variable, but it is not really much of an object (at least, not in the sense that it's commonly used and understood by practitioners of Object-Oriented paradigm). I'm aware that there are CPAN modules that implement Exception classes, but the fact is they're not integrated into the language at the deepest levels. (Whether that's a good thing or bad is, well, opinion I guess.)
| [reply]
[d/l]
[select] |
