What scripts? The ones you write? Do you follow your own advice? 
Yes and yes as much as humanly possible - forgive me if I don't see the point of this. Are you going to post some useful comments or just troll?
What are you paying these authors?
Nothing - I avoid using these modules because they *dont* check for write errors which is what I've said all along, and for some bizare reason you've chosen to ignore.

Do I generally pay the authors of modules I use or the perl developers? No, though a previous company I worked for did heavily sponsor Embperl development - I would always consider sponsoring a module author if a module showed promise and could be useful to us - as a salaried employee I'd prefer it if sponsorship came from the company rather than my own pocket though :) I've donated code to a CPAN project and a tiny bit of stuff to KDE, and am happy to donate code/advice to authors (which may or may not be useful!) - that's generally how things work in the OS world isnt it. Don't forget that a lot of bug reports are probably coming from developers using code heavily in commercial environments, and that does help the whole community in a more indirect way.

Ok seeing as I know this is going to go into a discussion on commercial companies and social responsibility etc - just because I mentioned money and companies does not mean I consider myself important or a great perl coder - I write fairly solid code but there are many developers in the perl community better than me (and probably better paid as well :). Some posters have implied that it doesn't matter if a script isn't robust - I'm respectfully saying that just isn't true - for other people such as myself, it's vitally important that scripts are 99.9% robust. Actually, unless you're just pratting around, I can't see any situation where silent data loss is desirable, but that's exactly what will happen if you use some of the modules on CPAN without a lot care.

I'm trying to emphasise the fact that if an author *chooses* to release to CPAN, and it is *their* choice, they really must think about sensible error handling before they release. Who knows what will be developed with/on top of that module, and what impact it may have later on?

If a script doesn't handle errors, at least the problem is localised to that script but, as we all know, modules are there for *reusable* code and that code might be used in thousands or millions of scripts. A module author therefore has to take some responsibility (heck, pride even!) for ensuring robustness - I'm not talking legal liability here, just a personal duty. If they can't or won't do that they should *NOT* release to CPAN - post it on their site, advertise it here, do anything else yes, but again - DONT PUT IT ON CPAN!

Code auditing is an answer, and depending on the project ranges from being to desirable to mandatory, but having to do a thorough audit on every CPAN module you use takes a lot of time and effort - as suggested by another poster, I need to look at the B:: stuff to see if that could help automate things - if I get something done (which wont be anytime soon) I'll release it here.


In reply to Re: Re: Re: Re: <rant>CPAN modules failing to check for write errors</rant> by Anonymous Monk
in thread <rant>CPAN modules failing to check for write errors</rant> by Anonymous Monk

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":



  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.