Exception silence is the worst (why programmers silence exceptions?)

Introduction, the purpose of this document

--The flow is to eradicate catch (Exception e) {} and write the poem that follows. --I wrote it as an Exception, but what is an error? How should I handle it? Consider --I want to tell the programmer, "It's better not to silence the Exception." --I want to tell the designer, "We should design to decide how to handle ultra-rare Exceptions."

Behavior of a programmer

―― "Oh, it's an exception. It doesn't occur, so I'm not sure, so you can just silently kill it. Catch (Exception e) {} is OK." ――This is the worst.

Let's change our position and think about it.

--The throwing Exception side is throwing because an abnormal situation has occurred (even if it is very rare).

What happens if you silence the exception?

--Even if an Exception occurs, it continues to operate normally as if nothing had happened. ――It's scary, but parents keep ignoring it even though they say, "My child has a headache!" ――Isn't it irreparable later? Do you regret it?

Why does the programmer (user) silently kill the Exception?

――Exceptions that are handled by design are handled properly, aren't they? (Retry of communication error) ――The problem is how to handle exceptions that are not decided by design. Therefore, the programmer chooses "The treatment has not been decided-> Silent killing is okay".

So what should we do with undecided exceptions?

――Let's "exception that has not been decided to handle → catch and throw as it is". ――This is the correct answer.

For those who wondered, "What? Can I throw an exception I don't understand?"

――In the first place, exceptions that are not handled by design are extremely rare exceptions. (There is no design because it is virtually impossible to occur) ――So it almost never happens. So, whether you silently kill or throw, the code isn't actually executed, so in that sense it's the same no matter which one you choose. ――But if you choose either one, throw is better than silent killing if you think about * if it happens *. (However, when it really happens, it will be the strongest ally)

To those who thought, "It's a very rare exception, and if it almost never happens, you can kill it silently."

――I think that it will almost never occur now, but when it enters the operation phase, it suddenly occurs. ――There is a limit to the range (design ability) that humans can imagine. Reality goes beyond that lightly. ――If you kill yourself silently, when the reality is over, your hands and feet will not come out. There are many things you can do in the development phase, but you will die in the operation phase.

To those who thought, "No, do you know what it means to throw an exception? The system will stop? I don't have the courage to write such a scary thing."

• I understand your feelings. sorry. Write the truth. ――Actually, this problem has a bad design. why? ――This is because we have not designed "How to handle ultra-rare exceptions?" So let's design.

For those who wondered, "No, how do you design a super rare exception?"

――For example, how about saying "A super rare exception is caught in the top class, logged as ERROR, and the system continues". ――See, you can throw super rare exceptions with peace of mind.

To those who thought, "No, even though a super rare exception has occurred, it is a problem with such a sloppy design of spitting logs and continuing the system."

• sorry. I don't know how to properly recover from a super rare exception (caused by an unidentified cause). ――In the first place, it is a very rare case, so please be patient with just the log output.

To those who thought, "No, even with ultra-rare exceptions, you can understand the cause of the occurrence. That's a problem if you don't design it properly."

――It's super rare, isn't it? It doesn't usually occur, right? Do you really design? ――You can't just design it, right? Man-hours will increase for mounting, testing, and operation, right? -Isn't it cost-effective? Are you prepared to bear it? ――So, do you really do it?