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

Some of these scripts drive the back ends for multi-million pound companies, I DO need to worry about how they handle errors.
What scripts? The ones you write? Do you follow your own advice?
Well it does matter for people doing this stuff commercially, and I wish (some) authors would start to realise this!
What are you paying these authors?
  • Comment on Re: Re: Re: <rant>CPAN modules failing to check for write errors</rant>

Replies are listed 'Best First'.
Re: Re: Re: Re: <rant>CPAN modules failing to check for write errors</rant>
by Anonymous Monk on May 30, 2004 at 10:47 UTC
    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.

      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!
      CPAN is for sharing, not for perfection. Outside of being polite, CPAN authors have zero social responsibility. This draconian sense of entitlement that you have is really repulsive and won't convince anyone, regardless of the validity of your ideas.
        CPAN is for sharing, not for perfection

        Of course, and who said anything about perfection - if you've read my posts here, I've never demanded perfection. Software always has, and always will, contain bugs (Apart from TeX, supposedly :)

        But CPAN is one of our most important plus points - perl without CPAN would be far less attractive. I've checked inside a few modules and have been a bit alarmed by some of them.

        Have you ever just installed something with CPANPLUS and gone with it? If not, I'll respectfully suggest you're probably in a minority. If, as you seem to suggest, CPAN authors can do what they want, is it ok to release a module containing a few system rm -rf calls in it? An extreme example, but little or no error checking can create real problems that are tricky to track down and may not become apparent until much later.

        This draconian sense of entitlement that you have is really repulsive and won't convince anyone

        Well that's IYHO - what draconian sense of entitlement exactly? Have you really read what I'm saying?

        I'm hardly being draconian by stating that it would be a good idea if CPAN authors always thought about error checking before releasing a module. That's good for everyone (ok, nearly everyone - I'm not attempting to be a spokesperson for anyone but myself), not just me, isn't it?

        I'm not arguing to prevent authors from posting code to CPAN, but maybe code should go through a basic audit (security, error checking etc) of somekind before reaching CPAN.

        If the argument is that anything can, and should go onto CPAN, then maybe ratings needs to be expanded to include security and error checking ratings - with the author always being given time to correct any problems before ratings are made public. That's the way a lot of commercial security issues are handled - maybe something similar could be introduced.

        Ok you don't like what I'm saying - that's fine. Please post your view instead - not a one liner if possible, but a more detailed discussion. I'm happy to try to understand where you're coming from, and based on that I'm open to modifying my own viewpoint - I really *don't* have fixed views on this, but what I'm saying *is* based off using code in production environments.

        Thanks