That is indeed an option, but I'm of the school of thought that it's better for a program or operation in a program to silently catch an error and correct it for the user than to just fail outright.

...and I'm of the school of thought that a program should silently toil away doing it's appointed task until it encounters something it's not expecting, at which point, it should be noisy as hell. Fixing something for the end user is not always the best solution, because what if your notion of "fixed" is different than what the user had in mind? The road to crufty code becomes short indeed.

On the other hand, if you want to subsribe to the "be liberal in what you accept and strict in what you output" philosophy (which is what I think you were getting at), that's fine, just don't do it silently. Document every feature that you have coded (as well as known limitations, bugs, etc...)

thor

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

But this assumes that your code can know what the user^W programmer (inserted later ... sorry) really wanted, which is a dangerous assumption. Why would I call new on an instance in the first place? Maybe it's a typo (I wanted the net method perhaps)? Maybe I really don't grok OO? Silently catching errors that arise at runtime through erroneous user input or network hiccups, etc. is one thing, silently catching a programmer's conceptual or didn't-read-the -API mistakes and correcting them is quite another.

It is your code though. But if you're ever going to distribute OO modules, I think it would be wise to warn (warn =) the user à la "new called on instance, a copy was created (did you mean to use clone) ?"

I mistrust all systematizers and avoid them. The will to a system shows a lack of integrity -- F. Nietzsche