nihil

Thread view:

Roedy Green - 06 Apr 2007 21:18 GMT

how would you code this:

catch ( java.io.IOException e )
{
// do nothing
}

Algol 68 had the nihil statement for explicitly saying you were doing
nothing. Java won't accept null by itself as a valid statement, though
it will accept function calls that evaluate to null.

Why not just a comment? Lint-like code inspectors think this is a
probable error.

Reply to this Message

Lew - 06 Apr 2007 21:23 GMT

> how would you code this:
>
> catch ( java.io.IOException e )
> {
> // do nothing
> }

Just like you did, except indented differently.

> Algol 68 had the nihil statement for explicitly saying you were doing
> nothing. Java won't accept null by itself as a valid statement, though
> it will accept function calls that evaluate to null.

It'll accept function calls that evaluate to anything, not just to null.

> Why not just a comment? Lint-like code inspectors think this is a
> probable error.

Why not just a comment?

Lint-like code inspectors are not as smart as you are. Most of them are
configurable, so perhaps you can train one to look for a comment instead of
barfing.

Signature

Lew

Reply to this Message

Stefan Ram - 06 Apr 2007 22:35 GMT

>how would you code this:
> catch ( java.io.IOException e )
> {
> // do nothing
> }

catch( java.io.IOException iOException ){}

>Algol 68 had the nihil statement for explicitly saying you were
>doing nothing.

Java has infinitely many null statements.

Choose one of

»;« (this is a statement with no effect),
»{}« (as used above),
»{;}«,
»{{}}«,
»{;{}}« (this has the length of »nihil«),
»{{};{}}«,
and so on.

Reply to this Message

Mark Space - 07 Apr 2007 00:55 GMT

>> how would you code this:
>> catch ( java.io.IOException e )
[quoted text clipped - 3 lines]
>
> catch( java.io.IOException iOException ){}

Most printed code I've seen does it this way, with the addition (iirc)
that the closed brace from the try identifier is also on the same line.

try {
// something...
} catch( java.io.IOException e ) {}
// next statement is outdented to here..

I prefer to line up the braces on the try identifier in the same column
like below, but most printed examples save line space and format as above.

try
{
// something...
} catch( ... // as before...

YMMV

Reply to this Message

Stefan Ram - 06 Apr 2007 22:43 GMT

> catch ( java.io.IOException e )
> {
> // do nothing
> }

Or, mocking books:

{ /* this block is intentionally left empty */ }

However, this is not my style.

But, sometimes such comments might make sense, as in:

switch( i )
{ case 3: engine.stack().checkIntegrity();
/* "break;" intentionally omitted, fall through */
case 4; engine.stack().reduce(); }

Reply to this Message

Eric Sosman - 06 Apr 2007 22:57 GMT

Roedy Green wrote On 04/06/07 16:18,:

> how would you code this:
>
[quoted text clipped - 9 lines]
> Why not just a comment? Lint-like code inspectors think this is a
> probable error.

My vote is for "just a comment" and for "don't let the
tail wag the dog."

Signature

Eric.Sosman@sun.com

Reply to this Message

Tom Hawtin - 07 Apr 2007 01:49 GMT

> how would you code this:
>
[quoted text clipped - 9 lines]
> Why not just a comment? Lint-like code inspectors think this is a
> probable error.

I think it's still probably an error even if the comment is present.
That's my experience anyway.

Do you really want to do nothing if some code is screaming blue murder?
Normally the catch block should at the very least throw new Error(exc);.
That's true even if you "know" it wont actually happen (like using
ByteArrayInputStream).

I guess you could silence static analysis tools by logging at finest level.

Tom Hawitn

Reply to this Message

Mike Schilling - 07 Apr 2007 23:43 GMT

>> how would you code this:
>>
[quoted text clipped - 15 lines]
> Do you really want to do nothing if some code is screaming blue murder?
> Normally the catch block should at the very least throw new Error(exc);.

There are circumstances when you simply don't care, for instance:

FileInputStream fis = new FileInputStream(fname);
try
{
. // read and process the first three lines of the file.
}
finally
{
try
{
fis.close();
}
catch (IOException ex)
{
}
}

If I can read and process what I'm interested in, it's of no interest to me
that the close fails.

> That's true even if you "know" it wont actually happen (like using
> ByteArrayInputStream).

I use RuntimeException for that, e.g.

String name;
try
{
name = new String(btyes, "UTF-8")
}
catch (UnsupportedEncodingException ex)
{
// Can't happen, since all Java installations support UTF-8
throw new RuntimeException(ex);
}

Is there a reason to prefer Error?

Reply to this Message

Tom Hawtin - 08 Apr 2007 00:29 GMT

>>> Why not just a comment? Lint-like code inspectors think this is a
>>> probable error.

>> I think it's still probably an error even if the comment is present.
>> That's my experience anyway.
[quoted text clipped - 19 lines]
> }
> }

If the close implementation was sufficient bothered to throw (I don't
know if any implementation of FileInputStream.close ever does), why is
that exception not important? (A better way to arrange the code, IMO, is
to remove that try/catch. You are writing extra code that says nothing!)

>> That's true even if you "know" it wont actually happen (like using
>> ByteArrayInputStream).

> Is there a reason to prefer Error?

Yes, very much so. You are making an assumption. Someday that assumption
may be wrong. If the assumption is wrong, throw an exception of some
sort. (Also, as a side-effect of good code in this case, the try block
can always end in a return without screwing up reachability.)

Tom Hawtin

Reply to this Message

Mike Schilling - 08 Apr 2007 10:00 GMT

>>>> Why not just a comment? Lint-like code inspectors think this is a
>>>> probable error.
[quoted text clipped - 26 lines]
> if any implementation of FileInputStream.close ever does), why is that
> exception not important?

What would you do in response to it? Youi've already read what you need
from the file. If, say, the network goes down at that point so that a
remote file can't be closed properly, that's of no importance to the running
of the program.

> (A better way to arrange the code, IMO, is to remove that try/catch. You
> are writing extra code that says nothing!)

I'm stopping the exception, which I want to ignore, from propagating.

>>> That's true even if you "know" it wont actually happen (like using
>>> ByteArrayInputStream).
[quoted text clipped - 3 lines]
> Yes, very much so. You are making an assumption. Someday that assumption
> may be wrong. If the assumption is wrong, throw an exception of some sort.

Yes, the code you snipped throws RuntimeException. I'm asking if you have a
reason to prefer throing an Error

Reply to this Message

Tor Iver Wilhelmsen - 13 Apr 2007 20:10 GMT

På Fri, 06 Apr 2007 22:18:50 +0200, skrev Roedy Green
<see_website@mindprod.com.invalid>:

> how would you code this:
>
[quoted text clipped - 6 lines]
> nothing. Java won't accept null by itself as a valid statement, though
> it will accept function calls that evaluate to null.

I generally configure Eclipse to give warnings about empty blocks; The
built-in linter will not accept single line comments as content, but
accepts a "proper" /* comment */ there as "non-empty"

As others have pointed out, there is an empty statement; however, that is
a dangerous beast, and Eclipse lets me flag it as the error it can be. The
most famous example of the danger of the empty statement is

if (a == b);
doSomething();

which will call doSomething() every time because there is an empty
statement after the "if". Perl and other languages solve this by requiring
a block; Java requires blocks for a lot of things (like try/catch/finally)
but foolishly not for while, for etc. Requiring them would have solved a
gazillion bugs where people typed ; at the end of the line out of habit
and only indicated the desired semantics with an indent on the next line...

Reply to this Message

nihil

Free Magazines