Object-Oriented Programming

A class can implement multiple interfaces because interfaces only define contracts without implementation. Multiple inheritance from classes is not allowed in C# due to complexity and ambiguity issues (the diamond problem). Sealed classes explicitly prevent inheritance by design.

Reflection can inspect event handlers, get/set property values dynamically, and allow cross-namespace access to type metadata. All these are valid capabilities of the System.Reflection namespace in .NET.

Option B shows correct Dictionary initialization syntax with proper type parameters and parentheses for instantiation. Option A is missing instantiation parentheses. Option C is missing parentheses. Option D uses wrong namespace (System.Text for StringBuilder is fine, but Dictionary needs Collections.Generic).

To solve this question, the user needs to know the hierarchy of Java exceptions and errors.

Both class Error and class Exception are children of the parent class Throwable. This means that any class that extends Throwable can be used to represent an error or an exception that occurs during the execution of a Java program.

Option A is correct because Throwable is the parent class of both Error and Exception.

Option B is incorrect because there is no class called Catchable in Java.

Option C is incorrect because Runnable is an interface in Java, not a class that represents an error or an exception.

Option D is incorrect because there is no class called Problem in Java that represents an error or an exception.

Therefore, the answer is: A

In exception handling hierarchies, a catch block can catch exceptions of its declared type or any subclass of that type due to polymorphism. If you catch Exception ( superclass), it will also catch IOException, SQLException, etc. (subclasses). This is a fundamental principle of polymorphic exception handling in object-oriented programming.

In Java, a class cannot be both final and abstract because these modifiers have contradictory purposes. 'final' prevents inheritance (no subclasses allowed), while 'abstract' requires inheritance (must be subclassed to be instantiated). This creates an oxymoron - a class that both requires and forbids subclasses simultaneously. The compiler will reject this combination.

Abstract classes can and often do have constructors. Although you cannot instantiate an abstract class directly, its constructor is called when a concrete subclass is instantiated using super() in the subclass constructor. This is useful for initializing fields defined in the abstract class that are common to all subclasses. The constructor executes before the subclass constructor's code.

In Java, it is syntactically legal to access a static member or method using an instance variable of that class, although it is discouraged as a bad practice because static members belong to the class itself.

Non-static inner classes are tied to instances of their outer class. You cannot create an inner class instance without first having an outer class instance, as the inner class implicitly holds a reference to its enclosing object.

Since Class Y is a subclass of Class X, an instance of Y can be implicitly upcast to a reference of type X. This is a fundamental polymorphic assignment in Java and compiles successfully.

To instantiate a non-static inner class, you must invoke the constructor on an instance of the outer class using the syntax new OuterClass().new InnerClass(), rather than calling InnerClass() directly on the outer class instance.

In Java, a method with no access modifier (package-private) can indeed be overridden by a method marked protected. This is valid because protected provides broader access than package-private, allowing subclasses (even in different packages) to access the method. The Liskov substitution principle permits widening access visibility in overriding methods.

Java requires a specific order for top-level elements in a source file: the package declaration (if present) must come first, followed by import statements, and then class/interface/enum definitions. This order ensures the compiler can properly resolve package and import information before processing type definitions. Options A, B, and E have incorrect ordering, while option C incorrectly states that imports and classes can be in any order.

Abstract classes in Java can contain fully implemented methods with bodies. Since both abstract classes C1 and C2 define valid concrete methods, the code compiles without any errors.

In Java interfaces, all methods are implicitly public and abstract. Explicitly adding modifiers like public (line 2), protected (line 3), or private (line 4) is not allowed. Lines 3 and 4 with protected and private modifiers are invalid. Option B correctly identifies lines 3 and 4 as erroneous.