This is the third installment in my series on sensible exception handling and will cover when and how to catch exceptions.
To quickly summarize, the series looks as follows:
Throwing Exceptions Using Assertions Catching Exceptions (this one) Logging Exceptions
The information in this post is divided [...]
This is the second part in a series of four on exception handling and it focuses on an area related to exceptions — assertions.
A quick summary of posts in this series:
Throwing Exceptions Using Assertions (this one) Catching Exceptions Logging Exceptions
Guidelines for assertions
An assertion [...]
This is the first post in a series of four on exception handling.
The series will cover what I think is a good and sound strategy for handling exceptions and errors in your application.
It is written with Java in mind, but is applicable to most languages which feature exceptions.
A quick summary of the coming posts:
Throwing Exceptions [...]
This is a bit of a rant, but I just gotta get it out of my system.
I’m getting frustrated by people I talk to who seem to misunderstand the whole point of agile software development (IMHO).
Different ways of reducing risk
The point with agile, as far as I understand, is to reduce risk and thereby costs [...]
Sometimes a constructor doesn’t communicate intention very effectively. This could be because instantiating the class in question isn’t as straight-forward as “creating a new object”, or because there are many alternative constructors. In those circumstances it might be useful to use well-named static or non-static methods to create instances of the class instead.
I want to describe a situation I came across where designing for testability seems to be in conflict with the always-valuable principle of loose coupling.
I’m constantly trying to become better at estimating how long a development task will take. As one step in this process I decided to create a simple web-based timer which I could use to measure time. Shouldn’t be too hard, I just needed a simple stop watch — the simplest thing that that could possibly work. That’s what I thought at least.
While evolving a design is good and nice one has to remember that even though big design up front might not be a good idea, all the hard design work still needs to be done at some point. Otherwise you’ll just end up with a big piece of garbage. Therefore, while starting with a story, do take time and think it through and answer a couple of the following questions for yourself.
I just wanted to describe what for me became an “eye-opener” regarding Test-Driven Development; that when you remove duplication, you should look for not only duplication of logic, but also duplication of data.
Among Java developers, there exist different ideas about how to implement the equals() method. The disagreement is about whether to allow subclasses to be considered equal or not. I quickly describe the difference between the two alternatives and give my take on the problem.