Recommended: Sing it, brah! 5 fabulous songs for developers
JW's Top 5
Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
if statements) to examine return values (to see if they represent error codes).
These tips and cautions will help you write better programs and save you from agonizing over why the compiler produces error messages.
catch clause completes, execution does not automatically return to the try block from where the exception object was thrown -- because the try block is no longer in scope. Instead, execution continues with the first statement after the catch clause. Suppose you have code that must always execute (whether or not an exception occurs). If that code appears in the
same try block as code that throws an exception, and if the "must-always-execute" code follows the code that throws an exception,
the must-always-execute code will not execute should an exception be thrown. This holds true for both C++ and Java.
It has been brought to my attention that some C++ compilers, such as Microsoft's Visual C++ compilers, make it possible to handle flawed code exceptions. If you have a C++ compiler, please consult your compiler's documentation to see if that is true for you."
Please answer the following question:
excdemo C++ source code and ExcDemo Java source code, why did I not combine, in the same try block, the code that pops integer values from the stack with the code that pushes integer values onto the stack?
Last month, I gave you three questions. Here are those questions and my answers (in red):
Prefix the shadowed variable name with the name of the class in which that name appears. The following ShadowAccessDemo source code demonstrates:
ShadowAccessDemo
// ShadowAccessDemo.java
class ShadowAccessDemo
{
static int field = 1;
static class NestedTopLevelClass
{
static int field = 2;
static class NestedNestedTopLevelClass
{
static int field = 3;
{
System.out.println ("NestedNestedTopLevelClass's field = "
+ field);
System.out.println ("NestedTopLevelClass's field = "
+ NestedTopLevelClass.field);
System.out.println ("ShadowAccessDemo's field = "
+ ShadowAccessDemo.field);
}
}
}
public static void main (String [] args)
{
ShadowAccessDemo.NestedTopLevelClass.NestedNestedTopLevelClass x;
x = new ShadowAccessDemo.NestedTopLevelClass
.NestedNestedTopLevelClass ();
}
}
When run, ShadowAccessDemo produces the following output:
NestedNestedTopLevelClass's field = 3 NestedTopLevelClass's field = 2 ShadowAccessDemo's field = 1
The following ClassFromInterface source code demonstrates:
ClassFromInterface
// ClassFromInterface.java
interface OpenClose
{
void open ();
void close ();
}
class ClassFromInterface
{
public static void main (String [] args)
{
OpenClose oc = new OpenClose ()
{
public void open ()
{
System.out.println ("Opening whatever");
}
public void close ()
{
System.out.println ("Closing whatever");
}
};
oc.open ();
oc.close ();
}
}
Interpret new OpenClose () as "create an object from an anonymous subclass of an anonymous class that implements the OpenClose interface." When run, ClassFromInterface produces the following output:
Opening whatever Closing whatever
Yes. The following NestedInterfaceInClass source code demonstrates:
NestedInterfaceInClass
// NestedInterfaceInClass.java
class A
{
interface OpenClose
{
void open ();
void close ();
}
}
class NestedInterfaceInClass
{
public static void main (String [] args)
{
A.OpenClose aoc = new A.OpenClose ()
{
public void open ()
{
System.out.println ("Opening...");
}
public void close ()
{
System.out.println ("Closing...");
}
};
aoc.open ();
aoc.close ();
}
}
When run, NestedInterfaceInClass produces the following output:
Opening... Closing...