1

Say I have a function that takes some arguments that fall under a bunch of constraints, e.g. one of them has to be an integer, another has to be a string of length at least 10, et cetera. In general, is it the function writer's (i.e. my) responsibility to have a bunch of asserts or whatever to enforce these preconditions, and throw errors if any are violated? Or should I just let the function proceed anyway and have the caller deal with any errors or weird output they get from it? My reasoning is that on one hand, it's simpler in terms of debugging if an error is thrown immediately when a precondition is violated, but on the other hand, it might be easier overall for the caller to read the documentation of the function rather than me padding it with a whole load of asserts and if-statements.

As a side question, if I'm writing functions that only I will be using, is the answer the same, or do I just do whatever I feel most comfortable with?

  • 4
    Are you in a cooperative or adversarial relationship with the people writing software that calls your functions? – whatsisname Oct 17 '16 at 19:42
4

Its important to check your parameters under some conditions.

  • You have a unit of work or transaction which you cant roll back half way through

  • The error thrown without checking would be unhelpful : "object is null"

  • No error would be thrown, but the result would be incorrect or confusing "and where name == null" != "and name == any value"

  • Expensive or time consuming work would be done to no result

But yeah, if you have a simple function and its going to throw a sensible exception anyway I wouldnt do parameter checking.

Also if you can write your function in such a way so that its hard for parameters to be wrong thats always a good thing.

  • "write your function in such a way so that its hard for parameters to be wrong" What do you mean? Could you give an example? – Bluefire Oct 18 '16 at 13:08
4

This is rather subjective, and depends on the cultural environment.

Generally, it is often a viable approach to:

  • throw exceptions in your public interface (i.e. do cheap checks on the inputs)
  • use asserts in your private code (check own calls, state, etc.)

Both tools support different kind of things: the first helps the user to use your code in the correct way. The second helps you to debug your code (what the other guy might not be able to do anyway).

Edit: The longer I think about this, the more I appreciate input/condition checking.

Say you're implementing function foo(some_input).

Someone else uses it, and at some point, the program crashes, with a stack trace down to your library. It's extremely hard to track down what went wrong, and it might not even start at foo(), but further down the line. The origin of the problem may seem completely unrelated to the conditions needed at your function. If your code saves state, it might happen hours later.

Who will be blamed? It looks like your code is broken (although technically it might be ok as per documentation). And it's virtually impossible to fix the problem without great efforts.

Or say the person also uses another 3rd party library, say function bar(). He might do:

some_input = bar();
result = foo(some_input);

And if problems arise, we can play the game of finger pointing, everyone just guessing who's the devil.

Bottom line: Be has helpful as you can! It will make life so much easier. You will get much less support request. And - best of all - you won't be held responsible for other people's bugs.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.