Get the Preplance app for a seamless learning experience. Practice offline, get daily streaks, and stay ahead with real-time interview updates.
Get it on
Google Play
4.9/5 Rating on Store
Object Oriented Programming · Question Set
Exception Handling & File I/O interview questions for placements and exams.
Questions
13
Included in this set
Subject
Object Oriented Programming
Explore more sets
Difficulty
Mixed
Level of this set
Go through each question and its explanation. Use this set as a focused practice pack for Object Oriented Programming.
Best practice is to catch only the exceptions you can handle, avoid swallowing errors silently, use meaningful logs, and rethrow or propagate when appropriate. This improves debuggability and system reliability.
For complete preparation, combine this set with full subject-wise practice for Object Oriented Programming. You can also explore other subjects and sets from the links below.
You create a custom exception when you need to represent a domain-specific error condition that built-in exceptions don’t model. For example in a banking app you may define `InsufficientFundsException`. The custom exception typically extends a base exception type, adds meaningful context (like account ID, amount) and is thrown when your logic detects the condition. This improves clarity of error handling and makes catch blocks more expressive.
When system resources such as file handles, database connections or sockets are not properly closed, the program can exhaust these resources over time, leading to errors or degraded performance. Proper cleanup via finally blocks or try-with-resources is key.
In languages like Java you can use try-with-resources which automatically closes the resource at the end of the block, whether an exception was thrown or not. This reduces boilerplate finally code and prevents resource leaks. For example: `try (BufferedReader br = new BufferedReader(new FileReader(path))) { … }` ensures `br` is closed automatically. This pattern simplifies error-safe resource handling and is preferred in modern code.
An exception is a runtime event that signals an error or unusual condition, such as dividing by zero or reading a missing file. Handling exceptions allows a program to respond gracefully rather than crashing.
In Java and C#, developers wrap code that might throw an exception in a try block, and then catch specific exceptions in catch blocks. This structure ensures that exceptional conditions are caught and managed rather than causing program termination.
The finally block follows try and catch blocks and is guaranteed to execute whether an exception is thrown or handled. It is typically used to release resources like file handles or close database connections, ensuring no resource leak.
In Java checked exceptions inherit from Exception but not RuntimeException. The compiler forces you to either catch them or add throws clause. Unchecked exceptions (RuntimeException) are not required to be declared or caught, giving more flexibility but less compile-time safety.
BufferedReader wrapped around a FileReader allows efficient reading of text from a file line by line, reducing I/O overhead. It’s a standard pattern for file input operations in Java.
Serialization converts an object’s state into a byte stream (or other format) so it can be written to disk or sent over a network. Later deserialization reconstructs the object. It is critical for persistence, caching and remote communication.
When a method does not handle an exception it propagates the exception up the call stack to its caller. You may wrap a low-level exception in a higher-level custom one (exception chaining) to add context while preserving original stack trace. Design APIs so that you throw meaningful exceptions, don’t leak internal implementation details, document exceptions a method may raise, and avoid over-catching (which hides bugs). Good exception design enables maintainable and clear error handling.
First, you surround file operations with try or try-with-resources to ensure cleanup. You catch IOException or higher‐level exceptions, log the file path, error nature and maybe retry or fallback. In finally (or automatically via try-with-resources) you close streams. You validate file existence and permissions before opening. In larger systems you might use abstraction over file I/O to inject mock streams for testing. Documenting and propagating meaningful errors completes the pattern.
Text I/O handles human-readable formats (like JSON, XML, CSV) and is easier for debugging and interoperability. Binary I/O uses raw bytes and is typically faster, more compact and used for images, performance-sensitive data or proprietary formats. For example you may serialize objects into binary form for cache, but write logs as text for readability. In code you might wrap streams accordingly and enforce encoding or endianness. Choosing correctly affects performance, maintainability and error handling.