Skip to main content

A Keyword Suggestion : 'check'

17 replies [Last post]
onderteker
Offline
Joined: 2004-11-25

In Java, I want to see a new keyword such as 'check'. Instead of
if(a<0){
return ;
}
I could write

check a<0;

In case the method has a return

if(a<0){
return false;
}

I could write

check a<0 ? false;

Even

check a<0 ? throw new

construct would be good.

I don't want this key word as a syntactic sugar. It increases readibility. But if there are too many error controls.
I like to simplify my programs.
But without this keyword, if statements look like business logic.
I could write

check isValid();
check isPaid(..);
check hasCredit(..);
check canDoThis();

All these methods can't be combined into one method.
Because that method would have a lot of parameters, and be too complex.
Also it should be modified in every change.
I don't know 'design by contract' or 'aspect programming' has this feature.
But I believe a keyword such as 'check' is needed.
Since exceptions improved error handling, this keyword would improve 'validation handling'.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
dog
Offline
Joined: 2003-08-22

> In my humble opinion, you should be using exceptions
> instead of doing all these checks. If you try to
> perform some operation on an object, and that object
> cannot support the operation because it is in some
> 'invalid' state, then the object should throw a
> declared exception
>

I reread your comment and now I think I understand you better. You are saying that instead of writing:

public void do(Data d) {
check(null != d);

...
d.writeTo(x);
}

that the check is unnecessary because d.writeTo() will throw the exception anyway.

I guess the answer to that is that I follow the "fail early fail hard philosophy" (McGuire, "Writing Solid Code), in which you want to trap errors as soon as you can because that way it is faster to detect the true cause. In this case the true cause is an illegal argument, something that check declares as a "precondition". NullPointer is NOT the cause, it is the symptom.

Now how about this:

public void writeAge(int age) {

check (age > 0);

writeToDb(age);
}

To send a negative age here is most absolutely wrong. It may or may not be that your database complains about the age being negative (but what if you were writing to a text file?).. so without the check this error can go undetected for a long time causing all sorts of data corruption and mayhem.

So "check", "assert" or "confirm" (my preferred lingo) are ways to mark a precondition. If the precondition fails the CODE SHOULD NOT BEGIN TO EXECUTE.

So my answer is no, objects don't magically throw exceptions, we need to check for the invalid states (only permit valid states to excecute).. or we're in big trouble.

jwenting
Offline
Joined: 2003-12-02

> public void do(Data d) {
> check(null != d);
>
> ...
> d.writeTo(x);
> }
>
> that the check is unnecessary because d.writeTo()
> will throw the exception anyway.
>
> I guess the answer to that is that I follow the "fail
> early fail hard philosophy" (McGuire, "Writing Solid
> Code), in which you want to trap errors as soon as
> you can because that way it is faster to detect the
> true cause. In this case the true cause is an illegal
> argument, something that check declares as a
> "precondition". NullPointer is NOT the cause, it is
> the symptom.
>

For which there is a perfect mechanism in the IllegalArgumentException which you can throw if your argument isn't valid.

What I see here is a typical attitude of the current younger generation to defer all responsibility for their actions to some authority while at the same time screaming that that authority is limiting their freedom of action.

If you were to simply introduce some validation of your arguments and throw an appropriate exception if they're incorrect you're failing even earlier than the function call itself which you should like.

In fact, doing so is the only proper way to do things, the function should never be called without correct arguments at all.

dog
Offline
Joined: 2003-08-22

[code]
package cool;

public class Check {

public static check(boolean condition, String message) {
if (!condition) {
// log, assertion failure in debug mode, etc..
throw new CheckException(message);
}
}

// other versions of check follow

}
[/code]

The problem with this thread is that if your check constraint fails you probably need to be throwing an exception, not returning (and thereby hiding the error). Also you may want to exactly and globally specify your check behavior for your particular app (that is why I don't use assert, for example).

Using it is simple in JDK 1.5:

[code]
import cool.Check.*;

public class Whatever {

public void doSomething(SomeData d) {
check(isValid(d));
check(isGood(d));
check(isOk(d));

... do work ...

}
}
[/code]

(no try catch because presumably CheckException is analogous to IllegalArgumentException or IllegalStateException).. but you can catch it in the appropriate places if you like too.

In conclusion: I already have the check "keyword" and it is better than anything suggested because it does exaclty what I want!

(the new Check() syntax is silly.. if you wanted polimorphism you couldn't achieve it that way anyways.. instead you could initialize Check to customized behavior if you're inclined to complexity)

jzacker
Offline
Joined: 2004-12-06

In my humble opinion, you should be using exceptions instead of doing all these checks. If you try to perform some operation on an object, and that object cannot support the operation because it is in some 'invalid' state, then the object should throw a declared exception

public void doSomething(SomeData d) {
try {
d.performSomeOperation();
} catch(SomeDataException e)
//wow, maybe you can actually do something smart here?
//Like logging, notifying the user or removing the
//object so you can't try this again?
}
}

There's your 'check'.

dog
Offline
Joined: 2003-08-22

errr.. that's exactly what "check" is doing.. When I call my check() method it tests the condition and if something is wrong it throws an exception.

The only reason I have a check() method at all is to make it more readable and easier to write. Writing:

if (a < b) throw new SomeException("there was an error");
if (a > c) throw new AntoherException("Another error");

is wordy to read and write so a method to make it easier is:

check(a check(a>c, "a not greater than c");

sometimes the descriptive message is not even necessary, and there can be checks that look for nulls, empty strings, and other such stuff..

In my programs I check arguments like this:

arg(a, "a");
arg(b, "b");

Where this checks to see that the arguments aren't null. And if so throws an IllegalArgumentException saying "a" is null. The compactness allows me to write a lot of these in my program without much pain making the program more robust without having all these nasty looking if statements all over. If it is easy I'll do it more.

jwenting
Offline
Joined: 2003-12-02

> Sorry, but this is the most non-sensical suggestion
> made in this forum so far.
>
and there have been quite a few :)

> "if (!requiredCondition) return;" is almost as short
> as and even more intuitively readable than
> "check(requiredCondition)".
>
He's not introducing a new function, he's introducing a keyword so no need for parenthesis...
This of course makes it even worse.

> Have you checked whether assertations maybe do what
> you want?
>
I think he's not checked enough yet...

What about things like
ifpos x (to replace if (x>0))
ifneg x (for if (x<0))
ifnull x (for if (x==null))
and of course the negated
ifnotnull x (if (x!=null))

would all be very (cough cough) welcome additions as well.

instead of his proposed

check x>0 {
return;
}

you could simply write
ifpos x return;

or make it even better: retpos x to return if x > 0 which would be capable of something like
retpos x y to replace the current
if (x>0) return y;

a million new keywords! A keyword for every possible comparison you could think of.

onderteker
Offline
Joined: 2004-11-25

I thanks for comments for my suggestion. But I still feel my 'need' for a keyword not understood well. I want it for readability, elegance and maintainability.

Just as 'enhanced for'. Let me say some more words.
I prefer to use a simple statement in a line. I write

String x=a.getX();
b.setX(x);

rather than

b.setX(a.getX());

I even prefer

LayoutManager layout=new BorderLayout();
setLayout(layout);

But in case of multiple validation controls I can't simplify code. I have to write

if( !isValid() && !isGood() && !isOk() )
return ;

or better

if(
!isValid()
&& !isGood()
&& !isOk()
)
return ;

In order to write different lines.

boolean ok=false;
ok&&=isValid();
ok&&=isGood();
ok&&=isOk();
if(!ok){
return;
}

This allows to add a new line without modifying another. It is nor easily readable. Worse, it does not return if a condition fails. In order to separate

checks I have to write

if( !isValid() ) return;
if( !isGood() ) return ;
if( !isOk() ) return ;

(Using 'notValid()' and using if without braces is against convention.) This code is not readable and not maintainable. Most of the modification in a project in

later phases comes as 'check'. Customers says 'Check this before doing that'. In order to add another check I have to change the code. I'd like to

check isValid();
check isGood();
check isOk();

Compare these statements, my suggestion is much clearer.
To add a new one, just write

check isReady();

Now, also, we have an new line and space to comment. In my opinion, a language must support programmer when it is impossible to do something by writing a

method or any other thing. Instead of 'check', 'return if !' may be introduced. In that case logic seems flow reverse. But in my mind, 'to check' is one

word, not two in reverse order.

Now Answers :
1. Assert is only to debug, and just the opposite of my suggestion.
2. Many keywords in Java have double meaning and we could live without them. For example 'while' means

if(condition)
stay in loop;
else
go out of loop.

Why we have 'while'? Why a new key word introduced? While could be done by 'go to'. While is added for to make code clear. Even 'for' is not needed. (I coded

in assembly!). My suggestion is not 'syntactic sugar'. It is at the same level as while,for, throw. I appreciate the idea that Java must have few keywords.

But if a new keyword, makes code more readable and maintainable, it may at least 'be considered'.

If you don't like my suggestion, I may sell my idea to C#!

Again thanks for comments and sorry for uninterested readers!

monika_krug
Offline
Joined: 2004-10-14

>In order to separate checks I have to write
>
> if( !isValid() ) return;
> if( !isGood() ) return ;
> if( !isOk() ) return ;
>
> This code is not readable and not maintainable.

This code is very readable and very maintainable.

>I'd like to
>
> check isValid();
> check isGood();
> check isOk();
>
> Compare these statements, my suggestion is much clearer.

No, it's not one bit clearer.

And it's less readable, because it is not stated that the method will return when the check fails.

> If you don't like my suggestion, I may sell my idea
> to C#!

Yes, go do that.

Monika.

asjf
Offline
Joined: 2003-06-10

you could try gratuitously abusing the existing language constructs to achieve something similar?

[code]
class Check {
static class CheckException extends RuntimeException {}
public Check(boolean condition) {
if(!condition) {
throw new CheckException();
}
}
}[/code]and[code]public void doSomething(SomeData d) {
try {
new Check(isValid());
new Check(isGood());
new Check(isOk());

... do work ...

} catch(CheckException e) {
return
}
}[/code]

hm

onderteker
Offline
Joined: 2004-11-25

I thank 'asjf' a lot for his/her solution to my 'problem'. I see he/she understands what I need and also understands (and, in my opinion, proves) that it can't be achieved 'easily' by Java language. 'A validation check per line' can be done by the suggested code. The only problem is less readable and may cause low performance (since a class is instantiated for every check). Still I may use the his/her solution since I can't change the Java language. In fact I use a similar one. A static method throwing an exception. In combination with import static, it would be more readable. But I still believe it is a language issue, not method or class.

(No, I won't sell my idea to C#. Even if use C# sometimes, I like Java. That's why I try to help to evolve it. But I bow in front of public opinion.)

Meanwhile, in the interview at

http://java.sun.com/developer/technicalArticles/Interviews/hamilton_qa2....

Graham Hamilton says

"It's more important that Java programs be easy to read than to write."

I totally agree. Because I write once but read many times, especially other developer's code. I believe, people commented on my suggestion thinks it is less readable. If it is so for everyone, ok, I give up. But If it is so and not introduced only not to increment number of keywords, it would be wrong. Because readability is much more important keeping number of keywords less.

Graham Hamilton also says

"Principles are good, but so are pragmatics. If we stuck too rigorously to our principles, we'd probably never dare make any changes to the language. It is natural for things to evolve, and we want to be able to make developers more productive, within the spirit of the language. But we are also very conscious that adding individually useful features may slowly undermine the deep values of the language."

To those who are conservatives of the most revolutionary language.

cowwoc
Offline
Joined: 2003-08-24

-1

onderteker,

First, I don't like your suggestion because it doesn't "mesh well" with the nature of Java as it already exists. There is something to be said about cohesiveness. Still, this is a subjective thing and I simply have a different opinion than you.

On the other hand, there is something you need to understand. It is *extremely* difficult to introduce new keywords into a language, not only from a technical point of view but also from a social point of view. If we're going to do such a thing, there has to be an overwealming evidence that the majority of the community likes your suggestion and will be positively affected by it. I am a strong believer in putting up strong resistence to any new feature requests within applications not to mention within Java itself. We are all best served by running new ideas through a tough gauntlet. Those that do not come out the other side might have been good, but not great enough to warrant the cost.

Feel free to bring up any other ideas you might have. They might be better received...

Gili

raytucson
Offline
Joined: 2003-09-16

A better solution may be the Null Object pattern. At a minimum it looks like it will save you many lines of code.

monika_krug
Offline
Joined: 2004-10-14

> In Java, I want to see a new keyword such as 'check'.
> Instead of
> if(a<0){
> return ;
> }
> I could write
> check a<0;
> In case the method has a return
> if(a<0){
> return false;
> }
> I could write
> check a<0 ? false;

Sorry, but this is the most non-sensical suggestion made in this forum so far.

"if (!requiredCondition) return;" is almost as short as and even more intuitively readable than "check(requiredCondition)".

Introducing new keywords is always hard, but in this case it would additionally be completely useless.

Have you checked whether assertations maybe do what you want?

Monika.

onderteker
Offline
Joined: 2004-11-25

Not to introduce a new keyword, 'return if' may be used.
Instead of

if(a>0) return 5;

we can use

return 5 if (a>0);

This seems the same. But, in this way we can discriminate between ifs that returns and ifs that goes on. My original suggestion was to separate ifs used for business logic from ifs used for validation. The construct 'if return' hides the information that the branch may return. 'return if' may be reverse in flow, but return is itself against the flow. Code goes on but execution not.

As another example

return if (notValid(a) && notGood(a) && notReady(a,b));

clearly says that this code returns. But

if (notValid(a) && notGood(a) && notReady(a,b)) return ;

hides the return. By the way, the same thing may be used for throw, as in

throw new IllegalArgumentException("Illegal") if (a<0);

In this way if is hidden, though. But return is more important to see. My aim is to clearly see the logic in the code.

patrikbeno
Offline
Joined: 2004-10-11

Oh no.

You are reversing logic: you have to evaluate expression before making the decision.
With

return 5 if (a>0)
throw new Exception() if (a<0)

you make decision (return/throw) before you check for condition.
Readability depends on expressions used. Consider this:

return (whatever+anything+retrieveValue() % 5) if (true)

If you want your 'return' more visible with lengthy conditions,write this:

[code]
if (notValid(a) && notGood(a) && notReady(a,b)) {
return;
}
[/code]

miojo
Offline
Joined: 2003-06-10

I believe isn't a good idea add new keywords to the Java Language.

Why don't you use a statement without braces?

if(a < 0) return;

Simple as is...

Add new keywords to the language are very complicated. Remember 'assert' ?

:)

subanark
Offline
Joined: 2004-11-26

I can understand the need to limit adding keywords, to allow upgrading code more easy.

So why not have keywords in packages that can be imported?
E.g.
import keyword java.checking.check;
Then check can be used as a keyword.
of corse if you did that then you could argue having code as formated:
[code]
@java.lang.Implements(java.lang.Cloneable.class)
java.lang.AccessModifiers.public class Foo
{
java.lang.AccessModifiers.package java.lang.Integer.int var1 = 5;
}
[/code]