Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl-Sensitive Sunglasses
 
PerlMonks  

comment on

( #3333=superdoc: print w/replies, xml ) Need Help??

That was a dramatic way to put it, but this does largely sum up why I prefer to use warnings during development but drop it when the code moves to production.

The users should not have to see Perl underwear, and are not expected to understand what they see anyway. But a developer should code until the warnings subside for all test cases, which should be fairly encompasing if you are using Test-Driven Development.

Turning the warnings fatal is in interesting escalation of the issue. I'm not sure I see the point for the vast majority of development, but then I trust that if I tell my developers to code with warnings on until none appear that they will do so.

I suppose I could imagine a corner case where recovery from bade code might be a huge inconvenience or take an inordinate amount of time. If the routine, for example, might risk deleting every row in a table and that would halt work by lots of developers or the restore might take a huge amount of time. But there are usually other ways to mitigate these kinds of problems, so I'm still not sure I buy into this approach to solve this kind of problem.

I could see one developer turning warnings fatal because they are the type who wants to fix the warning as soon as they bump into it, so this makes a one-line way to force the code to stop immediately so the errant code can be adjusted. And then perhaps forgetting to remove it before checking the code back in to source control. Such a situation could cause another developer to suddenly start seeing lots of warnings->FATAL references, I suppose.

I would be inclined to make checking for that a step during the process by which code is promoted into production. Especially since I am a proponent of the no-warnings-in-production philosophy anyway, this would automatically be caught in that net.

But I find it terribly rude to force end users to see error messages which are not generated in a context they are expected to understand. They are not likely to be computer scientists or software engineers, and may not even like the "{explitive deleted} computer" in the first place. The last thing we need to be doing is showing them error messages they cannot hope to understand, did not cause, and which were generally designed for us computer geeks to see.

Have mercy on the user. Ultimately, they pay our salary.


In reply to Re^2: Difference Between use warnings and use warnings FATAL => 'all' by marinersk
in thread Difference Between use warnings and use warnings FATAL => 'all' by Jim

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



  • 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 or How to display code and escape characters are good places to start.
Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others meditating upon the Monastery: (1)
As of 2022-05-20 17:59 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    Do you prefer to work remotely?



    Results (75 votes). Check out past polls.

    Notices?