C# is one of the most powerful languages in the modern world of programming. It has one of the most powerful type systems. There was a battle for some time between Java and C# and now we can say for sure that C# won that battle from the language features point of view.
C# 6 is already released and fully available with Visual Studio 2015. C# 7 is under development still, but many announced features are already implemented and we can play with them in Visual Studio 2017 which is currently (when I’m writing this) itself under development (release candidate is available).
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:
I’m excited to announce that my new “API in C#: The Best Practices of Design and Implementation” course is now live on Udemy. You can take it with 60% off!
In this course, over 3.5 hours, you’ll learn how to build simple yet powerful APIs, avoiding a great number of troubles.
You can open any C# tutorial and you’ll find some information about abstract classes and interfaces. Most likely, you’ll not find any information about what is the difference between abstract class and interface.
This theme was discussed earlier on the Internet several times but I want to consolidate all the most important thoughts regarding the problem of choosing between an abstract class and interface in this post.
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.
Have you heard about the “goto fail” fail? This is a security bug which was introduced by Apple in one of the iOS updates. Long story short, there was a piece of unreachable code which had to perform an important security check of a certificate. But it was unreachable. This is a huge defect in the software of this kind. Any meaningful static analysis tool would find that defect and any meaningful developer would fix such a bug after that. What am I talking about is that the cost of lately caught bugs is much greater than the cost of a bug caught at compile time. I don’t know how the hell Apple slipped up like that, but we are not going to discuss that. We are going to talk about static analysis.
Don’t forget that if you want to get my upcoming video courses with 50% discount, then fill the following form.
C# provides many ways to compare objects, not only to compare class instances, but also structures. Actually, there are so many ways, that it requires to put them in order. All those possible options of comparing confuse people in case of misunderstanding them and their possible implementations.
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;
Are you sure know the difference between the following events?
That’s a well known question. Actually, I knew the difference between methods and properties long ago. Despite of that, recently I stumbled upon my own incorrect choice between those semantic constructions. That’s why I decided to write this post – in order to solidify the understanding of the difference between property and method.
Method vs Property fail in BCL
The most notorious fail of creating a property inside the BCL (FCL) in .NET instead of a method is the DateTime.Now property. In my opinion, this particular case is not the worst in history, though it’s an embarrassing one. So, what’s wrong with that the DateTime.Now is implemented as a property rather than a method? This isn’t wrong from the point of the actual implementation, it is implemented correctly, the point is that this is semantically wrong from the API design perspective. If every time the getter of a property returns different values, then this is a method, not a property. Why? Because a property is an attribute of an entity. For example, Year is an attribute of a Date, so it would be correct to get the year as it follows: DateTime.Now().Year. Yes, that’s it, that’s how it should look like, not like a chain wreck – DateTime.Now.Year. By the way, similar by the case Guid.NewGuid() member is implemented as a method. In this case, the word “New” dictates that this should be a method, but for example they could have named it Guid.Next and even in this case it should be a method, as well as the DateTime.Now!