Handling Errors and Exceptions in C#. Part 3

This is the third and most comprehensive part about handling errors and exceptions in C#. Here are the first and the second part. Also, you can take a look at the blog post about global exceptions handling in WPF applications.

Errors Handling and many other topics you’ll find in my new video course “API in C#: The Best Practices of Design and Implementation”. Take it with 60% discount! Also, nothing can stop you from reading further)))

The problem of errors handling is really an old one. Despite that, I feel a lack of sources which aggregate the information and reveal all the problems relate to exceptions.
The first question which immediately comes to mind is “Why we need to understand how to properly handle errors?” There are at least two reasons:

  • Do not piss out the users. I know too many applications which fail without even telling the user what went wrong;
  • There is a category of applications which are very errors-sensitive. These are the applications which deal with huge financial

You can open any book on C# and see that for handling (or representing) any unfortunate situations such as validation fails, the critical system fails authors suggest to use exceptions.
The topic is a little bit holy war because there are no silver bullets, but it doesn’t mean that we don’t want to understand the problems which accompany exceptions using.
Several years ago, I asked Uncle Bob about the problems of using exceptions and he replied:

Continue reading

Designing and Implementing API in C#

Nowadays I’m writing my new programming video course. I chose an interesting topic for the next course: “Designing and Implementing API in C#”.

How to design API? In this course, you’ll learn how to design and implement types in C# so that the other developers won’t hate you when using one of the types developed by you. It means you are going to learn how to write code of the high quality: readable, understandable and reliable.

Improve your knowledge in object-oriented programming in the context of clean coding and building types of high quality.

  • Understand the characteristics of a well designed type
  • Grasp the principles of the convenient API development
  • Write clean code, get rid of unpleasant smells
  • Learn about what exceptions are intended for and how to throw and catch them properly
  • Protect your types from the incorrect usage making them properly encapsulated

And this is far from the full list of topics we will cover in this course.
Continue reading

Money Type as Value Object, or Don’t Rely on Primitive Types!

Primitive Types Obsession Problem

Today I’m going to discuss the problem of using primitive types instead of abstractions. This problem was discussed in the blog of Mark Seemann. Read it, if you haven’t read it yet.
In this post I’m going to talk about Money type as an abstraction instead of using decimal type for representing money-values.
In the last project I’ve been participating in, we relied on a decimal and integer types for a long time. From the beginning, we knew that using primitive types for values of that kind is an anti-pattern, but we stubbornly have been using them. In the US there are cents and dollars. In the Russian Federation – rubles and kopeks. 1 ruble = 100 kopeks. Our system inter-operated with an external system which performed all its calculations in kopeks. So it required kopeks as the input and returned kopeks as the output. If we wanted to pass in 2rubles and 50kopeks, then we passed in Int32 amount = 250;

Continue reading

Hidden Dependencies as a Smell

Mark Seemann has written a nice post  “Service Locator violates encapsulation”. The name of the post speaks for itself that it’s about a pattern (anti-pattern) named Service Locator. When a programmer arbitrarily inside the code base calls for the IoC-container to resolve a dependency of an object – he uses a Service Locator anti-pattern. Mark provides the following example:

public class OrderProcessor : IOrderProcessor
{
    public void Process(Order order)
    {
        var validator = Locator.Resolve<IOrderValidator>();
        if (validator.Validate(order))
        {
            var shipper = Locator.Resolve<IOrderShipper>();
            shipper.Ship(order);
        }
    }
}

Continue reading

Null-Checking Semantics Obscurity

This topic is going to be simple, yet an interesting one. I’ll try to expose here my feelings about a certain case of null-checking.
It’s a well-known fact that introducing null-values considered by its inventor, Tony Hoare, as a billion-dollar mistake. Despite of some “modern” practices like making classes immutable, applying Null-Object pattern or using Code Contracts extensively, we still often want to declare an instance of an object as null (no instance). I’m not going to discuss the fundamental problem of null-values. Instead of that, I just want to consider a specific case concerning null-checking.
Several months ago I was reading some code in a ViewModel and stumbled upon a method implemented as it follows:

bool CheckCard(CardDescription description, out CardReadingResult readingResult) {
    readingResult = null;
    if (description != null) {
        CardReadingResult r = device.SearchForCard(description.CardType);                
        if (r == null)
            Notify("Card was not inserted.");               
        else {
            var info = CardInfoParser.GetInfo(r.CardInfo);
            if (info.Number == description.Number) {
                readingResult = r;                        
            }                        
        }
    }
    return readingResult != null;
}

Continue reading

Refactoring: Extract a Method, When It’s Meaningful

Big Functions Hell

Well, now it’s hard to remember the moment, when I first time realized that it’s actually a good idea to extract functions from the massive chunks of useful code. Either I got this knowledge from the “Complete Code” or “Clean Code” – it’s hard to recall. Actually, it does not matter so much. We all know that we should split the business logic into well named functions. The longest function I’ve seen in my life was longer than 5k lines. I’m personally acquainted with that “programmer”. I remember when I first time faced that function. It’s not difficult to predict, that my very first reaction was – “WTF!!! Who made this piece of shit???” Yep, and that “programmer” is still hanging around in the office where I’m working on. I don’t want to get deeper into this story, but I want to mention that the 5k-lines-function was the core of the ~150k-lines program. That program was eventually driven to a corner because of that piece of shit, which tremendously influenced on the whole architecture of the application. In the end, the decision was made to rewrite that program completely from the ground.

Continue reading