Check out my new course Learn you some Lambda best practice for great good! and learn the best practices for performance, cost, security, resilience, observability and scalability.
By default, arithmetic operations and conversions in C# execute in an unchecked context, you can use the checked keyword to switch a block of code to the checked context so that any arithmetic overflow that occurs in that block of code will cause the OverflowException to be thrown:
However, the scope of the checked context is local to the method – i.e. if in your checked block you call another method then that method is not part of your scope and can cause arithmetic overflow without throwing any exceptions:
This might seem strange at first, but the reason for it is that whether or not an exception should be thrown for an arithmetic overflow/underflow is baked into the MSIL code the compiler generates rather than a runtime decision. When the OverflowInt method above is compiled, it’s compiled to NOT throw any exceptions when an overflow occurs, therefore regardless of where the method is called from no OverflowException will be thrown from inside the OverflowInt method.
However, it is possible to change the default behaviour for a given project by making a simple change to a project setting. Right-click on a project (inside VS) and go into project properties, find the Build tab, and click “Advanced…”. In the subsequent pop-up dialog there’s a ‘Check for arithmetic overflow/underflow’ checkbox:
F# uses a different approach, it uses operator shadowing so that whenever you open the Checked module it overloads the standard arithmetic operators to include checks for arithmetic overflow/underflow and throws the OverflowException:
Suppose if you have the following module, the function f will not throw exceptions for arithmetic overflows because at the point it is defined the arithmetic operators have not been overloaded yet:
Subsequently, if you have code that uses this module, the overloaded operators from the Checked module will not apply here just because you’ve opened an module that imports the Checked module:
It is possible to simulate the behaviour of the C# checked keyword as Tomas Patricek suggested here, although his solution only works for the int type but nonetheless it gives you a good idea of how one might be able to do so:
I specialise in rapidly transitioning teams to serverless and building production-ready services on AWS.
Are you struggling with serverless or need guidance on best practices? Do you want someone to review your architecture and help you avoid costly mistakes down the line? Whatever the case, I’m here to help.
Check out my new podcast Real-World Serverless where I talk with engineers who are building amazing things with serverless technologies and discuss the real-world use cases and challenges they face. If you’re interested in what people are actually doing with serverless and what it’s really like to be working with serverless day-to-day, then this is the podcast for you.
Check out my new course, Learn you some Lambda best practice for great good! In this course, you will learn best practices for working with AWS Lambda in terms of performance, cost, security, scalability, resilience and observability. We will also cover latest features from re:Invent 2019 such as Provisioned Concurrency and Lambda Destinations. Enrol now and start learning!
Check out my video course, Complete Guide to AWS Step Functions. In this course, we’ll cover everything you need to know to use AWS Step Functions service effectively. There is something for everyone from beginners to more advanced users looking for design patterns and best practices. Enrol now and start learning!
Are you working with Serverless and looking for expert training to level-up your skills? Or are you looking for a solid foundation to start from? Look no further, register for my Production-Ready Serverless workshop to learn how to build production-grade Serverless applications!
Here is a complete list of all my posts on serverless and AWS Lambda. In the meantime, here are a few of my most popular blog posts.
- Lambda optimization tip – enable HTTP keep-alive
- You are wrong about serverless and vendor lock-in
- You are thinking about serverless costs all wrong
- Just how expensive is the full AWS SDK?
- Many faced threats to Serverless security
- We can do better than percentile latencies
- Yubl’s road to Serverless
- AWS Lambda – should you have few monolithic functions or many single-purposed functions?
- AWS Lambda – compare coldstart time with different languages, memory and code sizes
- Guys, we’re doing pagination wrong
- Top 10 Serverless framework best practices