@KonradRudolph Java takes this non-final-by-default mistake to the extreme. Methods are virtual by default. This is dangerous design. I'm sure many compatibility issues are caused by the fact that API consumers override things that were not designed to be overridden.

Any language that makes classes non-final by default has made a mistake. C# made that mistake for example.

Is your question about division by zero or about exceptions in general? You might want to clarify the question with respect to that.

@user253751 this is a very interesting line of reasoning. In my opinion, user mode TCP stacks could be a very good thing. But many processes want to use the same NIC to receive network packets. There needs to be some global mechanism to dispatch such packets to individual processes. This is why kernel involvement is required. But there are user mode TCP stacks as libraries which take complete ownership of a specialized NIC. This does exist.

@8bittree maybe you're right. I was thinking of the case of allocating an array of references. There either has to be some default value or some way to ensure that elements are not accessed before initialization. I don't think that can be done in general.

It might be a billion dollar mistake but it's also a billion dollar gain. It is not easy to create a language without null references that also is efficient and general purpose. The fix for the "mistake" is not clear.

This is the common sense answer. Checking API results is additional work. You do that if it's worth it (not always). Also, many things cannot be checked at all and must fundamentally be trusted.

@sanyash your job is never done as long as you work there. Your job is to help the company as much as possible using any means available to you. Cooperate.

It is worth noting that many projects do not have a need for some of the lanes shown in this diagram. Some projects only need what's called develop and feature here. This is often true for web apps that can be deployed at will.

@Logarr And then there are people who have 1000 methods of 1 line in order to really just do one thing :) int IncrementCounter(int i) => i + 1;. The SRP does not define what "one thing" is. It's good as inspiration, not usable as a rule.

When code is removed nobody notices it ever existed. That makes it harder to recover. There is value in leaving commented code, especially if it seems likely that it will be used in the future.

Yes, this is a significant downside to using async. In my opinion, this downside is widely underestimated in the community.

You seem focused on adhering to fairly specific patterns. Instead, focus on the best overall solution regardless of whether it matches any pattern or not. It seems that your if based code or the array would be a totally fine solution.