There has always been confusion and debates on what to do with “exception” and how to use it. Now, if you see “exception handling” in context of just a programming practice, or java, or a convention, you are sure to get challenged by both your team members and yourself. During my early years, I have been in turmoil for making right decisions on it. But over the time, I have learned lessons and found the real purpose of exceptions which I am gonna share today:
I have found some more usages of “special case pattern” coined by Martin Fowler and I have tried to name them rhetorically to make you remember – dummy, dead, and deformed.
There are some underlying theories behind software architecture and structure that every software engineer must know. On the face of it, a developer may not face a situation where this knowledge is applicable, but there are situations in development where one may have any idea where the problem exactly hides. If you really want to know why overdriving yourself and your team is not helping you to get things done and dusted, I recommend you to study some subjects.
Handling null can be problematic in code organization and management. So, there are two very common patterns used by experienced developers now and then. One is “Null object pattern”, where you return an object which states a missing object, and another is “Special Case Pattern”. This article is to “How you can write effective objects for those patterns and why you should use them instead of returning null or throwing exceptions”
I read through many discussions related to Singleton Patterns, and different developers dislike it for different reasons. Not all the reasons make a pattern evil, because many of those reasons doesn’t really make your software really bad. I will be writing here each of the reason, and try to explain whether the reason is justified to call Singleton Evil:
