Exception hierarchy, errors

"Hi, Amigo!"

"Hi, Ellie! How's life?"

"Excellent, thank you. How are you?"

"Great, this morning tons of new things were explained to me."

"Well, that's great. You aren't tired?"

"Yeah, there's that. I'm a little tired."

"Then you just got lucky. I wanted to cover a large, complex topic today, but at the last minute I changed my mind and decided to cover a small, easy one."

"Small and easy? I'm ready."

"Today we'll examine the topic of Exceptions in detail."

"Are you talking about error handling?"

"You shouldn't think of exceptions as errors. Exceptions are more like reports that 'something unexpected happened'. Based on these reports, you can propose alternative actions."

"It's all about methods. When you call a method, it promises to do what it was called to do."

"When a method, for whatever reason, can't do what it was called to do, it has to let the caller know."

"In other words, the worst thing that could happen is for a method to not do its work and not tell anyone about it. Nothing could possibly be worse than that. You lose control of the situation when that happens."

"When you're a new programmer, it seems like you just call methods and they are sure to do what you asked them to do."

"When you're an experienced programmer, you know that there may be dozens of factors that affect a method's ability to do its job, and that there are a lot of cases that could prevent a method from completing its job."

"From the programmer's perspective, it's a thousand times better if a program terminates when it encounters an error than if the program encounters an error and then continues working (incorrectly) without the user realizing what happened."

"So the program showing something wrong might be worse than if the program closed and lost all of the data?"

"What made you think that the program is simply showing something incorrectly? Maybe the programs has lots of bugs and all your data will be irretrievably lost? Suppose you've typed in text for 3 hours, but none of it will be saved because an error that occurred after just two minutes."

"When a novice programmer encounters exceptions, he gets frustrated."

"But in reality, exceptions reveal all the possible scenarios that he should've foreseen but didn't."

"You could choose to not handle exceptions and that would make you a bad programmer. But if your methods don't throw exceptions, then you are no programmer at all — because you failed to understand this simple truth:"

"a method either does what it was written to do, or it throws an exception. There is no third option!"

"Okay, I believe you. I promise to use exceptions."

"Great. Then let me tell you about the hierarchy of exceptions:"

"The exception hierarchy is based on four classes."

"The lowest base class is Throwable."

"The Error and Exception classes inherit it."

"RuntimeException inherits Exception."

"The Error class is the base class for JVM errors such as StackOverFlow, OutOfMemory, …"

"A program usually can't recover from such errors, which leads it to terminate."

"Indeed, what can be done if there isn't enough memory for the program to continue running normally or there has been a stack overflow?"

"Exception is the base class for all ordinary exceptions thrown by a program. RuntimeException is a special kind of Exception that has slightly different rules."

"What are they?"

"That is just what I'm going to explain now."

"As you probably remember, exceptions fall into two categories: checked and unchecked."

"If a method throws checked exceptions, then the method that calls it must wrap the call in a try-catch block. Well, either that or rethrow the exception (to its caller) by clearly indicating throws in the method signature."

"These rules/restrictions don't apply to unchecked exceptions."

"So, all exceptions that inherit Exception are considered checked. Except for exceptions that inherit RuntimeException, which are considered unchecked."

"Uh-huh. I remember you telling me something like that earlier."

"Amigo! They ask about the exception hierarchy in every interview. I'll say it again — every interview. You need to know this topic perfectly."

"OK. I'll read everything again and figure it out. Thanks for helping me, Ellie."