Example code that skips error handling, unless that is made clear in the accompanying text, is an example of how to do something badly. I'm sure you didn't intend it like that, but error handling and considering edge cases are the key to writing robust reliable code.
Optimising for fewest key strokes only makes sense transmitting to Pluto or beyond
| [reply] |
Well, jdporter says: "handle the arg list being empty. You probably don't want to throw a divide-by-zero exception."
I am actually fine with that error code!
I have written Perl code that intercepts various warnings in situations where I can actually fix the problem. I remember one sort routine where a numeric comparison didn't work and the code defaulted back to an alpha comparison. There is no "fix" for a "divide by zero".
I added comments about this in further code. Grandfather is right about that. Document limitations.
In the code, allowing Perl to throw a "divide by zero" exception is fine.
The code is short. Detecting and printing an error that "will happen" is unnecessary,
because there is no "fix" for that error.
| [reply] |
Detecting an error condition and printing a usage message however is vastly nicer than expecting the user to dig through the code enough to understand why something blew up, possibly miles away from the actual error.
The "error" message then does two things, it provides run time documentation for unexpected states, and it subtly provides usage information during maintenance or casual reading of the code. As I said before, error handling and considering edge cases are the key to writing robust reliable code. The "consideration" part needs to be expressed in the code.
Optimising for fewest key strokes only makes sense transmitting to Pluto or beyond
| [reply] |