Presentation given at LeasePlan digital about alternatives to error handling in C# following a more functional way.
There is no built-in mechanism to represent the possibility of failures or errors in a typed manner in C#. Usually C# Developers rely on exceptions and NULL to represent non successful scenarios, the problem with this approach is that error handling is not clear. This problem can be addressed by the usage of code docs but I would rather have it strongly typed so developers can't just skip the error check when it is required.
There is no indication that operation can fail neither how to handle any error.
Problems
- It can throw NullExceptions
- There is no indication it can fails so the client doesn't know if exceptions need to be catched
- It is not clear if null checks are required
public class NaiveRepository
{
private readonly IAmazonSQS _amazonSqs;
private readonly string _sqsUrl;
public NaiveRepository(IAmazonSQS amazonSqs, string sqsUrl)
{
_amazonSqs = amazonSqs;
_sqsUrl = sqsUrl;
}
public async Task<IEnumerable<ImageDataPoint>> GetAllAsync(CancellationToken cancellationToken)
{
var response = await _amazonSqs.ReceiveMessageAsync(_sqsUrl, cancellationToken);
return response.Messages.Select(x => JsonConvert.DeserializeObject<ImageDataPoint>(x.Body));
}
}This approach makes use of null as return to failure scenarios but there is no details of the failure and sometimes null is a valid result so the failure is mixed with the absence of data
Problems
- There is no indication it can fails so the client doesn't know if exceptions need to be catched
- No details about the error/exception
public class ItNeverHappenedRepository
{
private readonly IAmazonSQS _amazonSqs;
private readonly string _sqsUrl;
public ItNeverHappenedRepository(IAmazonSQS amazonSqs, string sqsUrl)
{
_amazonSqs = amazonSqs;
_sqsUrl = sqsUrl;
}
public async Task<IEnumerable<ImageDataPoint>> GetAllAsync(CancellationToken cancellationToken)
{
try
{
var response = await _amazonSqs.ReceiveMessageAsync(_sqsUrl, cancellationToken);
if (response.HttpStatusCode != HttpStatusCode.OK)
return null;
return response.Messages.Select(x => JsonConvert.DeserializeObject<ImageDataPoint>(x.Body));
}
catch (OverLimitException e)
{
Console.WriteLine(e);
return null;
}
}
}Several packages provide typed solutions inspired in the functional approach to type operations results, below you can find my favorite solution using the Language-ext
public async Task<Either<Error, IEnumerable<ImageDataPoint>>> GetAllAsyncEitherBased(CancellationToken cancellationToken)
{
try
{
var response = await _amazonSqs.ReceiveMessageAsync(_sqsUrl, cancellationToken);
if (response.HttpStatusCode != HttpStatusCode.OK)
return Left<Error, IEnumerable<ImageDataPoint>>(new Error(ErrorCode.General, "Something happened"));
var imageDataPoints = response.Messages.Select(x => JsonConvert.DeserializeObject<ImageDataPoint>(x.Body));
return Right<Error, IEnumerable<ImageDataPoint>>(imageDataPoints);
}
catch (OverLimitException e)
{
return Left<Error, IEnumerable<ImageDataPoint>>(new Error(ErrorCode.FailedToCommunicateToAws, exception: e));
}
} The operation result is represented(wrapped) in the Either type. The Left part represents the type which wrappes the error scenario, it could be just a simple error message or as advanced as you may need, in this example I've created an Error class that can store the exception details, error code and more details. The Right part contains the actual result.
The client of this function now must handle the possibility of error.
var either = await resultRepository.GetAllAsyncEitherBased(CancellationToken.None);
either
.Right(values => Console.WriteLine(values.Count()))
.Left(error => Console.WriteLine(error.Message));- Strongly typed operations
- Clearly identify operations that can fail
- No need to inject Loggers everywhere just to catch error messages