You have come to C# at an interesting time. Until relatively recently, the language sat firmly in the imperative programming space. Using exceptions to communicate errors was definitely the norm. Using return codes suffered from a lack of language support (eg around discriminated unions and pattern matching). Quite reasonably, the official guidance from Microsoft was to avoid return codes and to use exceptions.

There have always been exceptions to this though, in the form of TryXXX methods, which would return a boolean success result and supply a second value result via an out parameter. These are very similar to the "try" patterns in functional programming, save that the result comes via an out parameter, rather than through a Maybe<T> return value.

But things are changing. Functional programming is becoming even more popular and languages like C# are responding. C# 7.0 introduced some basic pattern matching features to the language; C# 8 will introduce much more, including a switch expression, recursive patterns etc. Along with this, there has been a growth in "functional libraries" for C#, such as my own Succinc&ltT&gt library, which provides support for discriminated unions too.

These two things combined mean that code like the following is slowly growing in popularity.

static Maybe<int> TryParseInt(string source) => int.TryParse(source, out var result) ? new Some<int>(result) : none; public int GetNumberFromUser() { Console.WriteLine("Please enter a number"); while (true) { var userInput = Console.ReadLine(); if (TryParseInt(userInput) is int value) { return value; } Console.WriteLine("That's not a valid number. Please try again"); } } 

It's still fairly niche at the moment, though even in the last two years I've noticed a marked change from general hostility amongst C# developers to such code to a growing interest in using such techniques.

We aren't there yet in saying "DO NOT return error codes." is antiquated and needs retiring. But the march down the road toward that goal is well under way. So take your pick: stick with the old ways of throwing exceptions with gay abandon if that's the way you like to do things; or start exploring a new world where conventions from functional languages are becoming more popular in C#.

You have come to C# at an interesting time. Until relatively recently, the language sat firmly in the imperative programming space. Using exceptions to communicate errors was definitely the norm. Using return codes suffered from a lack of language support (eg around discriminated unions and pattern matching). Quite reasonably, the official guidance from Microsoft was to avoid return codes and to use exceptions.

There have always been exceptions to this though, in the form of TryXXX methods, which would return a boolean success result and supply a second value result via an out parameter. These are very similar to the "try" patterns in functional programming, save that the result comes via an out parameter, rather than through a Maybe<T> return value.

But things are changing. Functional programming is becoming even more popular and languages like C# are responding. C# 7.0 introduced some basic pattern matching features to the language; C# 8 will introduce much more, including a switch expression, recursive patterns etc. Along with this, there has been a growth in "functional libraries" for C#, such as my own Succinc<T> library, which provides support for discriminated unions too.

These two things combined mean that code like the following is slowly growing in popularity.

static Maybe<int> TryParseInt(string source) => int.TryParse(source, out var result) ? new Some<int>(result) : none; public int GetNumberFromUser() { Console.WriteLine("Please enter a number"); while (true) { var userInput = Console.ReadLine(); if (TryParseInt(userInput) is int value) { return value; } Console.WriteLine("That's not a valid number. Please try again"); } } 

It's still fairly niche at the moment, though even in the last two years I've noticed a marked change from general hostility amongst C# developers to such code to a growing interest in using such techniques.

We aren't there yet in saying "DO NOT return error codes." is antiquated and needs retiring. But the march down the road toward that goal is well under way. So take your pick: stick with the old ways of throwing exceptions with gay abandon if that's the way you like to do things; or start exploring a new world where conventions from functional languages are becoming more popular in C#.