Testing dynamic languages

[Tim Wintle]

On Sat, 2009-04-04 at 06:37 -0700, grkuntzmd at gmail.com wrote:
> If I am writing in Python, since it is dynamically, but strongly
> typed, I really should check that each parameter is of the expected
> type, or at least can respond to the method I plan on calling ("duck"
> typing). Every call should be wrapped in a try/except statement to
> prevent the method (and program) from crashing when my method is
> called with an integer instead of the expected string.

At some point you should wrap it in a try/except block - but only at the
point where you want the exception to be handled. That will normally be
quite far up, and you'll just let the exception travel back up to that
point.


for example, in a web server type of thing you might have something
vaguely like


def main:
  for request in request_itter:
    try:
      headers = request.get_headers()
      dispatch = get_dispatch_fn(headers)
      response = dispatch(response)
    except:
      send_500()

You probably then don't need to catch any exceptions in the get_headers,
or actual processing methods (unless you are writing to sql or
something, when you might want to wrap all statements in a try block,
and then put a "ROLLBACK;" query in the except block (and then raise the
caught exception so it goes back the the block above)

> 
> Is this the experience that Python programmer (of large projects) see?
> Do you also write unit tests to confirm that the methods actually
> check for and catch "bad" parameter types? If I am writing small one-
> off scripts, I wouldn't worry about it, but if I am writing a large
> system that must have 99+% uptime without constant monitoring, this
> really should be verified.

I write large applications with a target of 99.9% uptime, and I don't
find it a problem. occasionally I have to check parameters, but that's
not very often

> 
> Up for discussion...
> --
> http://mail.python.org/mailman/listinfo/python-list