public methods

> Should public functions check if the passes parameters

> are what they are supposed to be(int, char, etc) or is

> the calling class responsible for that ?

First: instead of public say "not private"

Second: no need to check for type safety, the compiler does it for you in these cases.

Third: as soon as you take a reference or have to stick to special semantics (like an int can only be 1, 2, 3 or 1000000), your question is relevant again.

In these cases, there are two different strategies.

- defensive programming: the method itself checks the validity of the arguments (nut null, within a certain range, whatever)

- programming by contracts: you define "the method takes an int value between 0 and 100". Whoever calls it has to make sure that the arguments handed to your method are appropriate or it's his problem if something goes wrong.

It's a philosophical discussion which is better. I mostly stick to the second one, because it's much less effort.

CeciNEstPasUnProgrammeur at 2007-7-7 12:50:11 >

> Or leave them on.

>

> I think, though, that assertions shouldn't be used for

> validating non-private method inputs.

Why not? Seems like a myth. Assertions is targeted as a validation tool to use during the program development phase. I see no reason why the non-privacy of methods should be a restriction. There are some rules for their best use though. They should for example not replace ordinary user input validation.

http://java.sun.com/j2se/1.4.2/docs/guide/lang/assert.html

UlrikaJ at 2007-7-7 12:50:11 >

> > Or leave them on.

> >

> > I think, though, that assertions shouldn't be used

> for

> > validating non-private method inputs.

>

> Why not? Seems like a myth. Assertions is targeted as

> a validation tool to use during the program

> development phase. I see no reason why the non-privacy

> of methods should be a restriction. There are some

> rules for their best use though. They should for

> example not replace ordinary user input validation.

>

> http://java.sun.com/j2se/1.4.2/docs/guide/lang/assert.h

> ml

In which case one could argue, if the input (for a non private method) is importent enough to validate, then why not just put the check in which will also be there in the final version of the class instead having something which will eventually need to be wirtten into something else and which just gives the same kind of 'usability' as an unchecked exception would ;)

Not that I'm critizising thier use, just that for non very complex things, I'll argue they are overkill.

NinjaGnu at 2007-7-7 12:50:11 >

> In which case one could argue, if the input (for a non

> private method) is importent enough to validate, then

> why not just put the check in which will also be there

> in the final version of the class instead having

> something which will eventually need to be wirtten

> into something else and which just gives the same kind

> of 'usability' as an unchecked exception would ;)

>

> Not that I'm critizising thier use, just that for non

> very complex things, I'll argue they are overkill.

Sure, assertions doesn't belong as "parameter validators" in public methods. Since I started using them more I've found lots of good uses for assertions and are lot's of places in the code where they feel natural, like catching a null pointer exception not where it happens but where it originates for example. It's great during development.

UlrikaJ at 2007-7-7 12:50:11 >

I agree that assertions are great to help you to do something foolish as you program, but at the delivering stage methods should have well defined and documented behaviour like:

"If null is passed as the file path the method will load the default settings and return" or

"if null is passed as the file path the method will throw a InvalidFileException".

Which one, depends on your design and the target of the code.

May the code be with you.

notivago at 2007-7-7 12:50:11 >