On Friday 02 February 2007 10:09, Adrian Howard wrote: > [snip] > I'm unconvinced that this should be the default behaviour because I'm > fairly certain that a number of these new test failures - possibly > the majority - won't actually be indications of code that doesn't work. > > For example. Module Foo uses objects from module Bar, which uses > objects from module Ni, which uses objects from module Fribble, which > has a exception in a DESTROY block that the author deliberately > doesn't catch because it doesn't signify an error in the code and > they know that exceptions don't propagate out of DESTROY blocks.
I don't even know how we could handle the exception out of DESTROY blocks but maybe this is already an error. I wish it would propagate and we could handle it. > Are you really saying you want the authors Foo, Bar and Ni to start > getting test failures because of a "mistake" in Fribble? Especially > since it's a "mistake" that has zero affect on the functionality of > Foo, Bar, Ni or Fribble? Unfortunately, you're twisting this a bit too much. I don't believe anyone on this list wants to force the re-write of all module tests (no, not even me). But I wouldn't mind finding an error in Fribble while I'm writing Foo because I would tell Fribble's author what I found and by making his module better, he will make mine more stable. Who says the error in the DESTROY block is no a very impotant error? What if the destroy block can't free a resource or set some variable that will be used in the next instance of Fribble? The point is not changing everything but having the right tools so we can change them if we so wish. Fortunately modules like your help and we just want them to help a bit more. Fame comes at a price :) Cheers, Nadim
