Best practices when using constructors – Redefined

In an older post, I suggested that constructors never should call methods, which possibly can throw exceptions. What also that blog entry explained, is that this idea mainly came from unmanaged languages like C++, where you could easily introduce memory leaks when a constructor throws an exception.

I however came back from that idea, since it also pollutes a lot of your code having to have initialization methods. You add hereby a unspoken contract that, after calling the constructor, you have to call the initialization method in order to use the class properly.

Read More…
Posted in Best practices, C# at December 1st, 2020. No Comments.

Moving from RhinoMocks to Moq

RhinoMocks is a framework for creating mocked instances, that can be used within unit tests. Since the framework is not to be maintained anymore (last version was in 2010), you can’t use RhinoMocks for example within .Net Standard or .Net Core projects.

A project I was working on was having the same struggle; we had quite a large set of unit tests that where using RhinoMocks. For several reasons, we decided to migrate our projects to .Net Core, which made it impossible to use RhinoMocks anymore. We decided to switch to the Moq framework. In this blog I summed up the most used RhinoMocks constructions and how to port them to Moq.

Read More…
Posted in C#, TDD, Unit testing at June 29th, 2020. No Comments.

Tasks and the AggregateException

When running a task asynchronous in an asynchronous environment, you can catch exceptions as you just using asynchronous code. When an exception occurs, C# will catch any exception and put it into the Task that will be returned to the caller. Furthermore, the Task becomes Faulted. The exception will be thrown now at the place where the await is put to wait for the result of the asynchronous call which caused the exception.

This changes however when calling a asynchronous task in a synchronous way.

Read More…
Posted in C# at August 13th, 2019. No Comments.

Passing exceptions between logical layers

Assume you have a layered system, build-up using the separation of concerns principle. We have a UI layer, a services layer and a database layer. The UI layer communicates with a service layer, which communicates with a database layer. As the names describe, the UI layer is responsible for showing an UI to the user, the services take care of main logic of the application and the data access layer communicates internally with a database.

Read More…
Posted in Best practices, C# at July 19th, 2019. No Comments.

Multiple return paths

Some argue that you shouldn’t have multiple return paths within our code. What are the benefits of having just one entry and one exit point?

Readability

You will keep the flow simple by having just one entry point and one exit point where the result is returned. In this case the code will be easy to read: you can simply read where the value is changed and where the end result is expected.

Controlling your object lifetime cycle

The main origin of the argue having only one return path, has its origin at languages like C or C++. In these languages you actually have to allocate memory when you want to use an instance of an object and deallocate it when you don’t need it anymore. If you forget the last one, you end up with memory leaks. Let’s say you create the instance and after that you return a value when some condition isn’t met. In this case, the line where your object is deallocated will not be called anymore.

A valid use: checking preconditions

A valid point where you could enter multiple return paths is at the beginning of a method, where you check the preconditions of your method. If a user of your method passes invalid arguments, you can quickly return a default value then have additional checks in your code.

 

Posted in Best practices, C#, C++ at June 12th, 2018. No Comments.

Prevent subscribing to an event twice in c#

Events in C# use the observer pattern, where an observer can subscribe itself to event generated by a subject. Within C# the observer can subscribe itself multiple times to the subject. When the subject fires the event, the observer gets multiple events.

The best way to prevent is to be keen on the life-cycle of your events; subscribe at the right place at an event en un-subscribe from the event also at the right place. How can we have a defensive mechanism, that prevents us subscribing multiple times at an event?

Read More…

Posted in C# at December 20th, 2017. No Comments.

What’s new in C# 7.0

With the release of Visual Studio 2017, C# 7.0 saw the light. By downloading the community edition of VS 2017, you can use the new .Net version right away. In this post, I will walk through the new language features, which mainly focus on data manipulation.

Read More…

Posted in C# at November 29th, 2017. No Comments.

Prevent changing the value of an object passed through a method in C#

Within C++, you have the const keyword, that can be used to say to the one which calls the method that the argument which passed through the const parameter won’t be changed within the method. This is merely adding a contract. Sure, the compiler does some checking for you, but still it is possible to change the value of your const parameter. See for example this nice example (obtained from https://isocpp.org/wiki/faq/const-correctness#aliasing-and-const):

Read More…

Posted in Best practices, C#, C++ at August 3rd, 2016. No Comments.

Require your application to run with administrator privilages

Sometimes your application requires to run with administrator rights. For example to access some restricted resources on a computer. Within .Net we can adjust our application in such a way, the user is asked to run the application with elevated administrator rights. In this way the application is executed with administrator rights, hence has less restrictions. Downside of this is that also more harm can be done with bad written code (think of erasing all files on the harddrive of a user).

Read More…

Posted in C# at February 9th, 2016. No Comments.

When to use or not to use var in C#

The var keyword let you declare a local variable implicit. During compilation, the type of the variable is determined. It allows you to quickly define a variable, where the type of the variable is trivial. Using the var keyword can lead to some discussion when code guidelines are made up, since some people say it makes programming easier but people may also argue that code is less readable. Read More…

Posted in Best practices, C# at June 25th, 2015. No Comments.