You make a good point when it comes to the public bit, if there is no obvious other user of the method it has no business being public (for the time being).
The method itself can still be valid for other reasons, SRP and encapsulation come to mind.

If Martin is really sure about his code then he doesn’t need to add a try/catch block to catch anything does he? (don’t use CheckedExceptions if you are working in Java) Remember that he is the source of the exception, not a victim.

However if he does make a mistake John’s method will make that apparent. This is a basic ‘fail fast’ concept. Without the exception Martin will first have to dig through John’s method to figure out what’s going wrong.

Also if Martin is unit testing his code he will get these same exceptions as his code calls John’s. In my view this will actually -help- Martin make his code more robust.

If Martin does call John with bad data I see it as a requirement that Martin handles this. How can John possible know how to resolve the issue, it’s out of it’s context? It’s a precondition thing; “I can’t service you given this”.

In a public scenario I do unit test for all exceptions on John’s method. I do not unit test private methods, if John’s method would be private I would test Martin’s method only.

Typically I don’t put pre-condition expections in private methods but I may put in some asserts which the compiler can drop when building a release.

Constraining the method input supporting on the compilers type checking is also a good solution, be it booleans, enums or whatever. Not always possible though.

Formal planning and requirements are key, but you don’t mention them at all. Not every program needs a complete suite of unit tests, it depends on the scope and lifecycle of the project. Similarly, performance is a requirement, and so should be quantified before any code is written.

And what if in the exception handler we run out of memory or the error logging connection breaks? Ah we need yet another layer of exception handling to handle the exceptions caused on the original exception handler – disks get full, you know. Or do you just “hope” the error message will be logged properly, or the dialog box will get on the screen. And we need unit tests for all that too…

This has gotten too long already, as would the code.

John should trust Martin is good enough, or if he isn’t change the interface so it depends neither on Martin’s ability to send good values, or John’s (and everyone else’s) ability to handle bad ones properly.

It seems very popular to fragment things into as many objects and classes and methods as possible, but this is bad design, not much different than being paid in KLoCs (thousand lines of code).

Often, when I hear a story like this (and I’m probably oversensitive), the two classes should be one larger class.

I’ve seen so much bad, fragmented C++ that suffered from this.

The designs I have seen that were blocked off into classes without trying to minimize the interfaces, and rules are put in place to “check everything” without a good guide as to what to do or even probability (the CPU is overheating so changes the value in its register).

If a method can only take two values make it a bool. If three, an enum or an array with 3 members.

If divide by zero will be a problem, try to mathematically transform it so you don’t need a divide.

Tell me how many new() methods do the right thing when memory allocation fails. Allocating statically might waste things at times, but the breakage is immediate and constant.

HDD is having a spare tank of gas, radiator fluid, and spare tire because you built the car to break down, or can’t be sure it won’t.

It is much harder to design the structure so that it can’t break, isn’t dependent, has no “invalid inputs”, but that will result in high quality code.

And it may not be harder than peppering exceptions and try/catch blocks through the code. Will you really code unit tests for EVERY exception condition?

Making it bool gives it two possible inputs and whatever complexity it does internally. Adding the test for validity means you need to test every other possible wrong input (e.g. 257 is treated like 1 instead of being detected), and then also write the code not to just examine the internal state change and outputs, but do whatever handling, typically exception handling, used to detect the error.

Then, since it is in the definition of that method, the test fixture for the calling class has to be modified to cause the same thing to happen – or not?

That was the conversation – does Martin’s class handle it when whatever error detection happens – if Martin ever sent a wrong value into John’s method, Martin’s class now needs to deal with the fallout – but how do you test that if Martin’s class always sends in correct data? Occasionally treat valid data as invalid to insure Martin’s upstream handling is OK?

Then there’s those who call Martin’s methods, if any (hence my merge the classes comment). Every one of them will have to handle whatever Martin does to handle John’s action in the invalid input case.

So now the code around the interface is 10x larger and more complex, and we really hope the unit tests we are writing will trigger things properly and that we didn’t miss anything or introduce more numerous and subtle bugs with the full and properly implemented validity checks at all levels than were likely to be there originally.

Or you code some simple, throwaway handling and use the same HHD you originally criticize to avoid validating the entire exception handling chain.

Try working through the original example and remove HHD completely, not just from the first level.

And my suggestion – make it a bool so it can’t be invalid by definition. The code still needs to be tested, but the number of cases is now far more limited.

Didn’t anyone else notice this?

Also, if the parameter isn’t A or B, does it throw and exception (so Martin needs try/catch all over the place)? Does it return a default value? Does it return it’s own Out of Band value? Does it simply do exit(666) into the abyss without leaving a stack trace?

What makes anyone think whatever John does in response to detecting the error won’t cause a worse problem than ignoring it?

Maybe it is
#define A TRUE
#define B FALSE
void martinsMethod( bool input) {
if (input != A && input != B ) …

No, the cancer is all those stupid design mistakes which are never corrected and arbitrary rules that created cluttered, complex code in the first place, but every method does all kinds of fancy checks for the most improbable events.

E.g. A 7 deep nest of methods will each dutifully check for a NULL pointer and just do nothing with it, so a security program which is validating a password will return OK instead of crashing with a segfault, letting the hacker through. I would rather it crash and halt than try to continue spinning who knows where.

HDD – Horrid Dogmatic Design – is writing out the design – all the classes – at random before you have any idea what you really need to do – and using Hope that you can turn the monstrosity that you refuse to fix at the higher level into something that works by doing a perfect implementation.