A couple of handy NetBeans features

[Harold Yarmouth]

Just thought I'd share these.

First, clicking a return type in a method declaration highlights all the
expressions within the method body that can cause the method to exit.
This seems to include checked exception throws, including method calls
that might throw, and returns. Useful if you want to find all the
returns to see which one is responsible for those unexpected and
troublesome nulls you've been getting, or whatever.

Stuff that can throw checked exceptions, but not any that escape the
method uncaught, doesn't get highlighted.

Second, clicking an exception class in the throws clause of a method
declaration highlights the expressions within the method body that can
throw that exception out of the method.

So if you have:

public int method () throws IOException, InterruptedException {
if (foo) {
sleep(1000);
return 0;
}
InputStream in = new FileInputStream(someFile);
try {
int bar = in.read();
if (bar == 'X') {
try {
doSomethingElseWithAnotherFile();
} catch (IOException e) {
// Ignore, will be retried later anyway.
}
}
} finally {
try {
in.close();
} catch (IOException e) {
// Ignore and let original exception propagate.
}
}
return 42;
}


clicking "int" in the method declaration will highlight the "return 0"
and "return 42" as well as the "sleep(1000)", "new
FileInputStream(someFile)", and "in.read()" expressions. Clicking
IOException will highlight the latter two. And clicking
InterruptedException will highlight the sleep.

The sole time this gets annoying is if I select a return type or
exception type in a method declaration in order to find occurrences of
that type in the file (which was how I discovered these features).

Overall, though, I find these handy. Finding all the exit points is
useful for debugging or just double-checking your logic, and finding all
the places that can throw some particular checked exception will also be
useful.

The IDE that shall not be named seemed to lack this feature the last
time I had to use it. I definitely recall actually deleting throws from
methods in it so that the IDE would highlight where the exceptions got
thrown -- by indicating an error. (Changing the return type to something
incompatible can find all your "return" statements similarly in any
auto-linting Java IDE.)

 

[Mark Space]

Just thought I'd share these.

First, clicking a return type in a method declaration highlights all the
expressions within the method body that can cause the method to exit.
This seems to include checked exception throws, including method calls

Neat. This works for a return type of "void" as well, which neatly
highlights the last statement of a catch(), as well as the final brace
in the method.

Second, clicking an exception class in the throws clause of a method
declaration highlights the expressions within the method body that can
throw that exception out of the method.

Awesome. I had never noticed either of these.


Some of my favorites include typing cntrl-space on a blank line, which
will auto-generate constructors for you, or getters and setters. It
actually brings up a large list of stuff, so if you press cntrl-space,
then start typing "set" for example, you restrict the list of offered
methods to just the setters. For this to work, you do need at least one
private field that needs a getter or setter.

Try making a simple class like this:

public class Employ {
private String name;
private long id;

}

Then put your cursor on the blank line, press cntrl-space and see how
fast you can generate:

1. A no-argument constructor.
2. A constructor which initializes both fields.
3. The 2 getters and 2 setters needed for the fields.


Double click on a method, variable or classname, then press cntrl-R to
rename the variable. If you need refactoring to rename (e.g., a public
classname) the refactor dialog will come up. Otherwise for something
like a local variable the renaming just happens in-place as you type,
without needing a dialog. Press return or click elsewhere or use a
movement key to leave this mode.


The refactor dialog is different if you right click on a class in the
Projects window. Especially the Copy and Move items can be handy.
These move an entire class to a a new package (very handy for when your
current package starts to get unwieldy, and you want to move some
classes to a new package), or for making a copy of an entire class. The
latter renames the class too, including all of it's constructors, so
this is much much faster than trying to use copy-paste and then go
through and manually rename everything.

 

[Harold Yarmouth]

The refactor dialog is different if you right click on a class in the
Projects window. Especially the Copy and Move items can be handy. These
move an entire class to a a new package (very handy for when your
current package starts to get unwieldy, and you want to move some
classes to a new package), or for making a copy of an entire class.

You can move a class to another package by simply dragging it there in
the package-hierarchy view.

 

[Qu0ll]

Just thought I'd share these.

[...]

Thanks, they are both cool and I wasn't aware of either of them. How did
you find them?

--
And loving it,

-Qu0ll (Rare, not extinct)
_________________________________________________
(e-mail address removed)
[Replace the "SixFour" with numbers to email me]

 

[Qu0ll]

Just thought I'd share these.

[...]

Thanks, they are both cool and I wasn't aware of either of them. How did
you find them?

Here's one way:
<http://wiki.netbeans.org/Java_EditorUsersGuide#section-Java_EditorUsersGuide-HowToUseHighlights>
part of
<http://wiki.netbeans.org/Java_EditorUsersGuide>

Don't'cha just love documentation?

Not as much as I love a smart arse

--
And loving it,

-Qu0ll (Rare, not extinct)
_________________________________________________
(e-mail address removed)
[Replace the "SixFour" with numbers to email me]

 

[Qu0ll]

Not as much as I love a smart arse

You ask where one can learn of these features. There you have a source.
You should be ecstatic.

Is it not normal to look at the documentation as a first source of
information? It should be.

I'm pleased that you enjoyed my response. But really, for the benefit of
all who use this group, "RTFM" is an amazingly potent principle.

Note that I do not claim that this is how the OP learned of these
features. I myself discovered them just by positioning the cursor on
these places and observing what got highlighted, along with noting the
options that turn this highlighting on or off. But your question sparked
a more general one in my mind, how could one learn of such features on
purpose? That's when I spent two minutes navigating to the netbeans.org
sites, where I already knew the documentation to be, and clicking on "user
guide".

The point of the "smart[-]arsed" remark was to remind all concerned in a
humourous fashion of the value of RTFM, that such FM exist for NetBeans,
where they are, and that one should use them. Valuable advice, no?

Lew,

Your advice is spot on indeed. I wasn't trying to suggest that these
features were not mentioned in the documentation; I was merely curious as to
how the OP came across them given that I had not encountered them and
because it was clear that it was not by reading the documentation or they
would have referred to it. I have to concede though that I have never RTFM
in relation to NetBeans. In fact, I rarely ever RTFM because most good
software is usable without it.

But I agree - if everyone did a bit more of RTFM then there would be far
fewer Usenet posts in the first place.

--
And loving it,

-Qu0ll (Rare, not extinct)
_________________________________________________
(e-mail address removed)
[Replace the "SixFour" with numbers to email me]