Naming things is one of the most difficult things in our job. Naming exceptions are even more complicated because exceptions are not regular classes. In this article, I’ll tell you a bit about naming conventions I’ve found and tell pros and cons of them.

The ‘Exception’ suffix. To add or not to add

There are two schools to add the suffix or not to add it. Let’s take a look a bit closer to see main pros and cons of both points of view.

When you have a very simple application it’s not so important to test every edge case but in a project, in the very complex domain, the priority of it will increase. The more high-quality the tests, the more high-quality the code. Mutational tests will help you with making sure you did not miss some a variant of the flow in your code.

How it works

• Mutational testing is a test which runs other test several times but with a bit changed production code in every iteration. Everything happens on the fly. The idea behind it is to check if your test will fail if you change something in your production code.
• Runs Tests without modifications. The tests should be green here.
• Parses the whole production code to find places where it can make a change.
• For every small change runs tests again and one of your tests should fail.
• If one of the mutations fail, the whole mutational test fails, too.
• Otherwise, the test succeeded.

I’ll show it in an example when it may be useful. Imagine you have a code like the above.

I’ll tell you a story of Igor. Igor is a web developer. He’s a young man with a girlfriend and some ambitious plan in the future. Igor sit at his desk because he has some work to do. In front of him is a PC. He turns it on and sees some system updates. 30 minutes have passed, and he can see his desktop with a beautiful wallpaper. Funny cats always make his day better. Some people are walking around his working desk, talking and drinking coffee. A typical day.

public:: true

• When the Go compiler cannot tell for sure that the variable under the interface won’t be used longer than the caller function lives, it will move the variable to the heap instead of the stack.
• When we run our code with a parameter -gcflags="-m" we’ll get (in the stdout) the heap escape analysis. The output will tell us what kind of compile optimisations are done during building a package.

• $ go tool compile -m demo.go
  demo.go:3:6: can inline demoFunction
  demo.go:8:6: can inline main
  demo.go:9:31: inlining call to demoFunction
  demo.go:4:9: moved to heap: data
  

• We can use it to finding out the reason why we have allocations on the heap rather on the stack.
• There can be many reasons why a variable escapes to the heap like:
  • [[Using interfaces in Go leads to moving to the heap]]