|more useful options|
Re^2: The Null Mull (or, when OO needs more O)by brian_d_foy (Abbot)
|on Nov 29, 2004 at 21:45 UTC||Need Help??|
Before I start, I'm not saying that you should use this in every situation. It has to fit the problem you are trying to solve. If you are in doubt about whether it fits into your problem, it probably doesn't.
That said, I think I've already covered your questions. You can still check the return values. If you got the error object, that's a failure. You can also figure out where things broke. That's an example in the original post. As for readability, you simply check the result and handle the error. Remember, I'm talking about the concept, not the recipe. If you understand the concept, you can implement it in several ways.People seem quick to wrap an eval around code
This metaphor gets rid of some of that kludgyness. Now an error is handled as normal program flow rather than an exception. Add logging and warning capabilities and other things behind the scenes instead of the script level.
This isn't syntatic suga. It's not extra syntax at all. It's less stuff at the script level. The program is designed to handle errors, not patched to catch them.
Don't get caught up in the method chaining. It's just one example. It's not always up to me what things I have to deal with and who else is writing code. I have to make things keep working even if other people chain methods. You don't have to shoehorn method chaining into Perl, either. It's there already. If you don't like it (and reasonably so), you don't have to design for it and you don't have to use it when the interface allows it. That's a personal preference, though. Other people do it, and I have to live with that. I'm trying to get away from people shoehorning exceptions into Perl, which is a true weakness. That's what all the eval and die nonsense is. ;)
It's not a maintenance nightmare at all. You simply document how to check a return value. The scripter doesn't have to know anything about it. They just use the interface. They get a result, and test that result for true or false (or however the rest of the system does things). The mechanics are homologous to testing a result code through a method like a lot of modules already have in their interface. If the coders aren't checking return values, the program still breaks at the same point.
But again, let me emphasize that you don't have to use this. Don't go looking for places to use this. Just file it away in your toolbox. Someday you might run into a situation where its useful, and those situations will come to you (not the other way around).
brian d foy <firstname.lastname@example.org>