Giters

jeastham1993 / aws-lambda-dotnet-handler-cookbook

This repository provides a working, deployable, open source based, AWS Lambda handler and CDK .NET code. This handler uses serverless best practices idiomatic to the .NET ecosystem and is ready for production usage.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Missing argument validation and null protection

Ubiguchi opened this issue · comments

commented

Building through the code, there's a lot of nullable warnings, caused by missing argument validations on public and protected members, nullable annotations and attributes. Given the aim of being production quality, it'd be great to cull all the nullable warnings.

Might need addressing in a few PRs, as it touches all bits of the solution. See https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/compiler-messages/nullable-warnings for details.

commented

Thanks @Ubiguchi great feedback, Ill work through these this week.

commented

All fixed :)

commented

Cool, that's helped with the warnings, but has got me all confused on the value of IDE-time null checking vs the traditional approach of validating public and protected parameters for nulls.

Traditionally I'd have said it makes sense to validate all public and protected parameters against nulls. For example, in StockTraderAPI.Program.FunctionHandler, I'd have gone with something along these lines:

    public static async Task<APIGatewayProxyResponse> FunctionHandler(APIGatewayProxyRequest request, ILambdaContext context)
    {
        ArgumentNullException.ThrowIfNull(request)
        ...

However, Visual Studio Code seems pretty confident that request isn't null, although I'm not 100% sure why. I know this is a bit far-fetched, but if the assembly was referenced from another assembly that called Program.FunctionHandler, then I'm pretty sure request could be null, meaning there's sarguably still some value in the explicit argument check, even if it's to protect against far-fetched usage scenarios.