Should we allow null/empty parameters? -


i had discussion co-worker on whether should allow null or empty collections passed method parameters. feeling should cause exception, breaks method's 'contract', if not break execution of method. has advantage of 'failing fast'. co-worker argues leads littering code 'not null/not empty' checks, when wouldn't matter.

i can see point, allowing null or empty parameters makes me feel uneasy. hide true cause of problem delaying failure!

let's take 2 concrete examples:

1) given have interval class overlaps(interval) method, should happen if null passed parameter? feeling should throw illegalargumentexception let caller know wrong, co-worker feels returning false sufficient, in scenarios uses it, doesn't matter if second interval null or not (all matters whether overlap).

2) given method fetchbyids(collection ids), should happen if empty collection provided? once again i'd warn caller abnormal happening, coworker fine receiving empty list, once again doesn't care whether there ids or not.

where responsibility of called code end? in both cases calling code didn't mind whether parameter null or empty, in other scenarios might point bug. should method guarantee won't break long preconditions adhered to, or should try identify potential buggy invocations well?

edit: see lot of answers , tend define contract/in documentation , stick it, i'd opinion on when allow , when not (if ever). in specific examples, do? given 90% of uses, not validating input fine, still validate flush out bugs in remaining 10%, or rather address appear , avoid unnecessary null/empty checks?

your cases 2 different situations map nicely real world:

1) given have interval class overlaps(interval) method, should happen if null passed parameter? feeling should throw illegalargumentexception let caller know wrong, co-worker feels returning false sufficient...

passing null here asking "what's difference between duck?", can't answer because there's information missing. can't punt , "there's no difference" because have no idea whether missing information duck (no difference) or water buffalo (big difference). if contract stipulates caller has provide compare , caller didn't hold end of bargain, that's reason throw exception.

2) given method fetchbyids(collection ids), should happen if empty collection provided?

this akin wife telling grab shopping list off refrigerator , pick on it. if there's nothing on list (empty collection), come home nothing , you've done asked. if go refrigerator , don't find shopping list (null), raise exception telling wife there's no shopping list there , can decide if meant tell on kitchen table or forget whole thing.

should method guarantee won't break long preconditions adhered to, or should try identify potential buggy invocations well?

as others have said, method should guarantee behave documentation says behave. if contract says method return result in presence of null argument, it's caller make sure knows it's passing null , able deal results.

how program should behave in presence of plausible-but-fishy data depends on lot of things, how important continue functioning or whether continuing process kind of data have adverse impact on else. that's decision you, developer, make on case-by-case basis using judgment. purports know should 1 way in every circumstance hasn't examined problem closely enough.

in cases elect not throw exception (e.g., returning false overlaps(null)), have option of logging fact saw questionable along whatever other information have available (stack trace, etc.). gives option of dealing out-of-band program continue functioning.


Comments

Popular posts from this blog

unicode - Are email addresses allowed to contain non-alphanumeric characters? -

C#: Application without a window or taskbar item (background app) that can still use Console.WriteLine() -

c++ - Convert big endian to little endian when reading from a binary file -