A lot of this is good stuff. To continue

1. I guess it depends on the context. Certainly in a situation where you can assume full server control, seperate logging would mean warnings can be turned on. I've done a lot of work in shared log uncontrollable server situations, and I've found that in that case more often that not the warnings are just getting in the way in that case, particularly when there's a warning that is relatively unimportant, but which end up filling up 95% of the log.

2. Interesting. I'll add that in. In my case, I've ended up with my own somewhat lighter Exception class, based around the die'able object ability.

3. Returning things by list like that has some major problems. Returning by list gives us no way of differentiating a legal null list from an error state. Take a better look at the suggested full map of return conditions, based on the return type and whether it can fail or not.

My standard is that when a method can error, undef is the error response, 0 the null response, and a list is returned by reference.

Only in the case of a list return with no possibility for error is the subroutine allowed to be written such that it returns a list.

Also, consider the problem of 'return' being inconsistent, for example in

Foo::maximum( $foo->value, $bar->value, $baz->value );
[download]

If an error was returned with just 'return', that code does not fail, but rather continues with an incorrect result. The alternative is create three new variables, save the values to them, check them, and THAN call Foo::maximum.

In the long term, over thousands of methods, I consider the predictability of having methods ALWAYS return error as undef outweighs any potential for the bug you mention. Return by list has it's own problems, and I choose to go with consistency.

4. I concur with the be careful, and I certainly agree. Within _my_ code, I generally don't overload isa, so it's save for me. And the VERY large number of times I use UNIVERSAL::isa means that the code is far more readable. When testing external modules, yes, there is reason to be careful.

5. Point taken

6. I agree, sort of. Certainly about the legibility being the main reason.

As for the memory saving, I measure a largish API once, and found 1500 post-ifs ( mostly 'or return undef' though ). That's heading towards a meg of extra overhead. I'm a little more paranoid about saving memory than most I guess. Note Config::Tiny and CSS::Tiny :)

7. I've swung either way on this one... At the moment I'm still leaning slightly towards regex still, from a flexibility viewpoint ( you can use the regexs for regex stuff ) and for their compactness. ( And they are quite legible )

8. I concur, I'll add a note. The whitespace example is really just that, and example. I should probably add the grep { regex; 1 } alternative, although using map {} makes it much more obvious as to the intent.

9. That is much nicer, and I really should have known that :)

10. The && 1. Never heard of it. If I saw it, I'd want to hunt you down with an axe. Try !!; simple, clean, only two ops, and each to teach as the "boolean context" operator.



Thanks for all the suggestions

---

---

• Are you posting in the right place? Check out Where do I post X? to know for sure.
• Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:

  <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>

• Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
• Want more info? How to link or How to display code and escape characters are good places to start.