Forum:

Java in General

doubt with return

Ranch Hand

Posts: 1282

posted 20 years ago

Number of slices to send:

Optional 'thank-you' note:

Send

inside a method, i want to test if a string is what i expect; else, i want the program flow to stop right there. Towards this goal i use the keyword return:

My Q:
does return does, properly, what i intend?
Or there is another, better, way of stopping the program execution?
thanks in advance
[ September 22, 2004: Message edited by: miguel lisboa ]

java amateur

David Harkness

Ranch Hand

Posts: 1646

posted 20 years ago

Number of slices to send:

Optional 'thank-you' note:

Send

By "the program flow to stop right there," do you mean exit out of the program entirely? Or do you simply want that method to exit and have the program continue on with its work?

If the former, you wantwhere <int> is an exit code: 0 means normal program exit; anything else typically means an error occured. It only matters what you pass if some other process is evaluating the return code.

miguel lisboa

Ranch Hand

Posts: 1282

posted 20 years ago

Number of slices to send:

Optional 'thank-you' note:

Send

i guess i mean the latter: if my var isnt validated, i dont want it inserted into database - so i want to stop the flow of the processing, not ending the app (i'm doing it with a warning msg dialog); else, its ok going on with insert

java amateur

David Harkness

Ranch Hand

Posts: 1646

posted 20 years ago

Number of slices to send:

Optional 'thank-you' note:

Send

Originally posted by miguel lisboa:
i guess i mean the latter: if my var isnt validated, i dont want it inserted into database

Then "return" is what you want. You can use it to exit a method even when you are not returning an actual value.

miguel lisboa

Ranch Hand

Posts: 1282

posted 20 years ago

Number of slices to send:

Optional 'thank-you' note:

Send

that's great knowing that, because i checked my two java books (thinking in java and head first java) and coudnt find a proper answer

thanks a lot again

java amateur

David Harkness

Ranch Hand

Posts: 1646

posted 20 years ago

Number of slices to send:

Optional 'thank-you' note:

Send

You will often find a certain disdain for control-flow-altering keywords like return (non-value), break, continue and goto. The weak argument is that you can always replace them with equivalent branching (if-else) mechanisms. I say weak because you could replace a lot of other useful constructs too, but as they say, "Use the right tool for the job."

The other argument is that they invite confusion. I personally find that, used properly, they improve understanding and readability. I've adopted the coding style of "exit early" methods: you attempt to exit from the method as early as possible. Compare these two implementations:

public void changePassword ( String oldPassword , String newPassword )
{
    if ( newPassword != null && oldPassword != null ) {
        if ( newPassword.matches(PASSWORD_REGEX) ) {
            if ( oldPassword.equals(this.getPassword()) ) {
                this.setPassword(newPassword());
            }
            else {
                throw new PasswordMismatchException();
            }
        }
        else {
            throw new InvalidPasswordException();
        }
    }
    else {
        throw new IllegalArgumentException("Passwords must be non-null");
    }
}
 
public void changePassword ( String oldPassword , String newPassword )
{
    if ( newPassword == null || oldPassword == null ) {
        throw new IllegalArgumentException("Passwords must be non-null");
    }
    
    if ( ! newPassword.matches(PASSWORD_REGEX) ) {
        throw new InvalidPasswordException();
    }
    
    if ( ! oldPassword.equals(this.getPassword()) ) {
        throw new PasswordMismatchException();
    }
 
    this.setPassword(newPassword());
}

I find the second version much easier to read. You don't need to maintain mental state or match ifs and elses to find which failure triggers which exception. It's also far easier to modify to add a new condition later.

That's my two cents, anyway.

As to why those books you mentioned don't cover it, perhaps it was implied or the index isn't very thorough.

miguel lisboa

Ranch Hand

Posts: 1282

posted 20 years ago

Number of slices to send:

Optional 'thank-you' note:

Send

I find the second version much easier to read

me too!

It's also far easier to modify to add a new condition later.

cant agree more

As to why those books you mentioned don't cover it, perhaps it was implied or the index isn't very thorough.

i'd add: maybe i wasnt able to properly find it...

Excuse me my basic following Qs, but i'm no pro at all, just a plain amateur:
are those 'this' really needed at all?
can one catch some of those exceptions with, lets say, a warning msg dialog?

thanks a lot again

java amateur

Layne Lund

Ranch Hand

Posts: 3061

posted 20 years ago

Number of slices to send:

Optional 'thank-you' note:

Send

It sounds like you are trying to deal with an error situation here. This is a perfect candidate to throw an exception, rather than simply returning. In such a situation, the caller should then decide what action to take.

One advantage to this approach is that you can separate the underlying database logic from the user interface. This will allow you to more easily change the user interface from a GUI to a text console or a Web app.

That's just my 2 cents ;-)

Keep coding!

Layne

Java API Documentation
The Java Tutorial

miguel lisboa

Ranch Hand

Posts: 1282

posted 20 years ago

Number of slices to send:

Optional 'thank-you' note:

Send

that's great, really
thanks for pointing it!

java amateur

David Harkness

Ranch Hand

Posts: 1646

posted 20 years ago

Number of slices to send:

Optional 'thank-you' note:

Send

Originally posted by miguel lisboa:
are those 'this' really needed at all?

No, but it's common style to include them to be 100% clear. Where they're necessary is in a standard setter method:Some people prefer to prefix all member variables with _ or m; others prefix their arguments with _ or the (theName); still others rely on the IDE to color the variables (Eclipse) based on the scope.

I used to prefer simply writing clear code and disambiguating the few cases that weren't obvious (or using "this" in setters). The more and more I have to deal with other people's code, the more I am thankful to see the "this."

can one catch some of those exceptions with, lets say, a warning msg dialog?

Absolutely! And as Layne pointed out, it will make your code much more reusable and maintainable. If you throw meaningful exceptions in the worker code (a data-access object for example), then your UI code can catch it and handle it (show an error dialog).

When you want to reuse that same DAO in a command-line or automated tool, you can catch it and print an error -- and exit(1) if severe -- or log a message. If you put the code to display an error dialog in the DAO itself, you're pegged to a GUI app.