[15] in java-interest

home help back first fref pref prev next nref lref last post

Re: more queries: exceptions, new and package

daemon@ATHENA.MIT.EDU (Arthur van Hoff)
Mon Apr 24 16:24:28 1995

Date: Mon, 24 Apr 1995 12:05:17 -0700
From: Arthur.Vanhoff@Eng.Sun.COM (Arthur van Hoff)
To: java-interest@java.Eng.Sun.COM

> From majordom@java.Sun.COM Mon Apr 24 09:13 PDT 1995
> From: jeremy@sour.sw.oz.au (Jeremy Fitzhardinge)

Hi Jeremy,

> Most of these questions are things which arn't addressed explicitly rather
> than real ambiguities.
> 
> The new operator:
> 
> What is its precidence?  I've made it about the same as unary ops,
> so it isn't confused with normal array operations (eg, so you have
> to use (new int[10])[4] to index a newly created array).

I think that is correct.

> Can simple types have initializers?  That is, new int(12) makes a
> reference to an int initialized with 12.

No. Integers are not objects so you can't new them. If you want a
reference to an java.lang.Integer you should use new Integer(12).

> Do constructors for complex types have to have parens?  Is (new
> Thing) meaningful on its own?

They must have parens.

> I'm confused about references.  Are all variables references to
> their instances, or are simple objects really there and complex
> ones references? 

Simple objects are "value" objects. They are copied in an assignment.
Arrays and instances are copied by reference.

> For example, what is the type of the expression
> "new int;"?  Is it just an int, in which case the new does nothing?
> What if I really want an int reference?

You can't have an int reference. We have added a set of utility
classes that allow you to wrap an object around an integer. Check out:
java.lang.Integer and others.

> Exceptions:
> 
> If you have something like
> 	try {
> 		foo();
> 	} catch(specific_thing a) {
> 		...
> 	} finally {
> 		tidy();
> 	}

You can't have a catch AND a finally in the same statement.
try-finally and try-catch are really different statements.
You should write:

	try {
	    try {	
		foo();
  	    } catch (Exception e) {
		...
	    }
	} finally {
	    toidy();
	}

> and foo() throws something which specific_thing doesn't match, does
> the finally block get run, as the exception passes through, or
> would you need to catch and rethrow Object to get that effect?

The finally methods is ALWAYS executed. That is the whole point.
You can even put a return in the try clause and it would still
execute the finally branch BEFORE actually returning.

> The syntax I'm using for try/catch/finally blocks is:
> tryblock: "try" block
> 	  ("catch" "(" arg ")" block)*
> 	  {"finally" block}
> 	;
> That is, catch and finally blocks have to be directly adjacent to
> try blocks, and it's possible to have a try block with no catch or
> finally.  Is this OK?

It is more like (the {}'s mean one or more):

	'try' <stat> { 'catch' '(' <decl-expr> ')' <stat> }
or

	'try' <stat> 'finally' <stat>



> Also, is the argument to a catch block allowed to shadow another
> local variable?  Is it just like a local variable declaration with
> a scope of the catch block?

Shadowing is discussed in the language spec. It is allowed but our
compiler emits a warning.

> The "package" statement:
> 
> The spec says in 6.1 that a package declaration must be the first
> non-comment thing in a file.  However, I've found that a number of
> files in the Java Alpha2 distribution (for example,
> classsrc/net/InetAddress.java) have import statements before their
> package statement, which javac accepts.  Is it wrong, or is the
> spec wrong?

That is wrong. It should be the first thing in the file. Thanks
for pointing it out.

> Casts again:
> 
> I've changed my parsing to match javac; that is, a (simple_type
> ("[" "]")*) is always a cast.  I also made it that (e1) op e2 is
> always a cast if op can only be a unary operator, but is a binary
> expression if op could also be binary.

I think that is right. 

How is your compiler coming along? Are you writing it in Ansi-C?
I would be interested to take a look at it some time...

Have fun,

	Arthur van Hoff (avh@eng.sun.com)
	http://java.sun.com/people/avh/
	Sun Microsystems Inc, M/S UPAL02-301,
	100 Hamilton Avenue, Palo Alto CA 94301, USA
	Tel: +1 415 473 7242, Fax: +1 415 473 7104

-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com

home help back first fref pref prev next nref lref last post