Java Deep

Pure Java, what else

Monthly Archives: May 2016

Try and Catch in Golang

Golang as opposed to Java does not have exceptions, try/catch/finally blocks. It has strict error handling, functions called panic and recover and a statement named defer. It is a totally different approach. Is it better or is the Java approach the superior? (Sorry that I keep comparing it to Java. I am coming from Java world.)

When we handle exceptional cases in Java we enclose the commands into a ‘try’ block denoting that something may happen that we want to handle later in a ‘catch’ block. Then we have the ‘finally’ block that contains all the things that are to be executed no matter what. The problem with this approach is that it separates the commands that belong to the same concern. We want to deal with some file. So we open a file and later, no matter what, we want to close it. When the programmer writes the finally block the file opening is far away somewhere at the start of the method. To remember all the things that we have to do to clean up the actions at the start of the method you have to scroll up to the start of the method where the ‘try’ block starts.

Okay! I know that your method is too long if you have to scroll back. Your methods follow clean code principles and are not longer than ten lines each including JavaDoc. Even though the issue is still there. It is formulated according to order the execution is expected and not according to the order the logic dictates. The logic says the following: if I open a file, I will want to close it. If I allocate some resource I will want to release it. It is better keeping the concerns together. We are not programing in assembly where you write the mnemonics in the strict order of execution. We define the algorithmic solution in a high level language and the compiler will generate the assembly. Real work has to be done by the brain, mechanical work is for the CPU. These days we have CPUs.

Golang has the command ‘defer’ for the purpose. You open a file and you mention on the next line that you will want it to be closed some time calling the function you provide. This is the much better approach, which the developers of the Java language also know hence introducing the interface ‘closeable’ and try-with-resources statement.

Still programmers coming from the Java world begin introduced to Go are longing for exception handling. If you really want you can mimic it in Go. It will not be the same and I do not really get the point why to ruin something that is good to something old and mediocre, but you can write

		Try: func() {
			fmt.Println("I tried")
		Catch: func(e Exception) {
			fmt.Printf("Caught %v\n", e)
		Finally: func() {

Homework: find out the sample code that is before these lines (Go constructs) that make this possible. Solution is here:

package main

import (

type Block struct {
	Try     func()
	Catch   func(Exception)
	Finally func()

type Exception interface{}

func Throw(up Exception) {

func (tcf Block) Do() {
	if tcf.Finally != nil {

		defer tcf.Finally()
	if tcf.Catch != nil {
		defer func() {
			if r := recover(); r != nil {

func main() {
	fmt.Println("We started")
		Try: func() {
			fmt.Println("I tried")
		Catch: func(e Exception) {
			fmt.Printf("Caught %v\n", e)
		Finally: func() {
	fmt.Println("We went on")

See also a recent similar solution at from Tim Henderson

Do not (only) meet the budget

In a previous article I wrote

The actual decision (of a software architect) should lead to a solution that meets availability, performance, reliability, scalability, manageability and cost criteria. (Btw: the first six criteria should be met, the last one should be at least met and minimized, but that is a different story.)

Many times the criteria are met and there is no intention to minimize the cost. “There is a budget and we have to fit into it.” This is the approach teams follow. There are several reasons for it. But the reasons do not necessarily mean that the approach is ok. I may even accept the argument that this behaviour is unavoidable in large organizations.

Why is this approach bad?

When you sell something you want to sell it the highest price you can. Cost represents a minimum for the selling price: if the reachable price is lower than the cost to reproduce then production will stop. Budget is also a limiting factor. You go to the food shop and you buy the bread that meets your likes and is the cheapest among those if you have the money. If your money is limited you will select one that you can pay for. Why would one buy the more expensive if all other criteria they need are met?

(Do not start to talk about Apple products: feeling you are rich is also a need.)

The same is true for development projects even if the customer buying the development is in the same company. Your customer is either “business” if you are an in-house team or sales in case your company develops software for customes. In the latter case the “customer customers” are the customer of the company. The customer of the development team is sales. Same company. Customer provides the budget that you have to fit in but

nobody ever complained that a project was under budget.

I am not talking about lower budget commitment. All projects have risks and all risks have financial impact. One way of risk mitigation is to have contingency in the budget. But again: that is the budget and not the actual spending. Still teams, departments tend to fill their budget. Why do they do that? There can be several reasons and sure I will not be able list all possible.

Reasons to spend more


The more a department spends the more important it looks. I have seen such company. The company was a large expanding company heavily investing into assets, building infrastructure for years (like telecom infrastructure, roads or railways, I won’t tell you which one) and the one who was building the more miles the better performer was. The measurement was the spent money and this culture remained when it was IT spending. Weird.


In some companies budget not spent will lessen the financing possibilities of the department for the future. If you, as a software architect can save up from the original estimates it means your estimation was not good. That will be taken into account next time you estimate. Thus the department rather wastes (usually towards end of the year) the budget left over than giving it back to treasury. It is like fixing a bug creating another. (How about unit testing departments?)


Some companies underfinance maintenance, developer trainings, education, equipment or some other IT related activities and departments tend to amend the situation from other sources: overbudgeting projects. Things certainly will happen. If you want to have something you do not pay for you will not get it. If you got it you paid for it just you do not know where, when and how much. Developers, architect, project managers may even not realize that they follow this practice in some cases. I have heard a few times the argument: “We select the more expensive technology X for the project because this way we can learn it.” This is also crossfinancing. You use the project to finance the developer’s education.

All these are bad practices. I do not need to explain the first example. The second is also quite obvious. The last one, cross financing is not that obvious.

Why cross financing is bad

When you select the more expensive technology (it may be more expensive because it has license fees, or needs more development, learning) you decide to invest the company money into something. As an architect it is not your responsibility. You may suggest that to management but you should not decide even if you are in the position that you can (unless you are also the management in a small company, but in that case you decide with your management hat on). It is only management who can decide how to invest the money. Investing into people is always a good investment even if they leave your company later. (But what if you do not invest and they stay?) But as a matter of fact management may see even more lucrative investment possibilities at that very moment.

Don’t feel bad

Do I suggest that you rush to management now and ask them to lessen your budget? Do I think that you, as a software architect should feel bad if you fill the budget and cross finance?

Not at all. I said that crossfinancing is bad practice but I did not say that it is YOUR bad practice. It is a bad practice implemented in a company. The larger the organization is the more difficult it is to change it. And it is not your task, and more importantly you may not have the capabilities to do that.

The only thing you have to: know that you follow a practice that is not optimal, so to say. If there is any chance to improve it just a little bit, go for it. Everybody making one small step will save the world.

Architects Don’t Decide

As pointed out in the article A Little Architecture from Robert C. Martin the job of the architect is not

…to lead a team and make all the important decisions about databases and frameworks and web-servers and all that stuff.

It is to make

decisions that a Software Architect makes are the ones that allow you to NOT make the decisions about the database, and the webserver, and the frameworks.

As the article pointed out juniors have many times different view about the tasks that a senior does than the senior who does it. It is not only the subject of the decision however. This is a bit more. Juniors see the position of an architect as a position of power. He has the right and the power to make decisions. Having the power is always good. You long to have the position of power, don’t you. Up to certain age, maturity.

When you get into the position of being an architect you realize that the power is not a privilege. It is a reponsibility. The system the team develops, the architecture, the network, hardware, the operation is not a play field to satisfy your curiosity. It is a professional environment that works based on profit and lost, budget and costs, money, money, money. The decision the architect makes should not be biased by the actual person’s interest. This is, by the way, a very common mistake. “Let’s use NoSQL because that is so fancy! We have to use big data!”

The actual decision should lead to a solution that meets availability, performance, reliability, scalability, manageability and cost criteria. (Btw: the first six critera should be met, the last one should be at least met and minimized, but that is a different story.)

The actual decisions on the architecture and solutions (finally when unavoidable also about framework and database and other stuff) depends on many things. License structure, license cost, company culture, available developers, deadline/time to market, architecture already in place to name a few. If you consider all the constraints you have to meet you will not have too many choices. There will be compromises and finally you will end up with the only one selection that fits. That one is going to be your decision.

Did you really make a decision?

Code Naked

  • I can not merge your pull request on our Git.
  • Why?
  • There is only one file modified.
  • That is because we modified only one Java class.
  • That is exactly the problem. I can not see in the pull request the modified JUnit test.
  • I could not modify the unit test because there was no any.
  • I see. And that is a problem of the past. The present problem is that still there is no unit test.
  • But we have no time to write unit test for the whole program. There are zillion of lines of code developed during the last few hundred years. They have no unit tests and they just work.
  • I acknowledge that. That is the life when you maintain legacy code. But why did not you write unit test for the change you just created?
  • There are zillion of lines already…
  • Yes, those that “work”. But your change is new. How do you know that it works?
  • We just agreed that we do not start to write unit tests now. We do ad-hoc testing.
  • Okay. Then let’s just get back to the basics. Why do we have unit tests? What is the primary reason?
  • To have working and tested code.
  • Im my opinion this is more like documenation. Unit test is a live documentation that is more likely to be maintained than any other documenation. You just created a few lines of code without documentation.
  • I get your point, but we just do not have time for that.
  • Let’s look at the following situation. It is summer and hot. You wake up late and want to rush to fetch the bus. You take the shower and drink your coffe and run to the bus. Right?
  • Right.
  • You do not even dress. Run out naked.
  • No! No! I dress!
  • But you have no time. You are in a rush. If you have time to dress yourself why do you let your code run to production without unit tests naked?
  • I get the point. But you can survive without unit tests. If you run on the street naked you will not survive.
  • Why is that? The summer is hot, you will not catch cold.
  • Yeah, but police would catch you.
  • So this is a kind of society issue, is it?
  • Yes, it is.
  • And the coding society is not that matured yet, it lets you run naked without unit tests.
  • I assume… yes.

we still have a long way to go ahead of us…