Open serapath opened 7 years ago
Hi @serapath, thank you for your question!
First I have to say that assertions are NOT drop-in replacement for Errors. Let's see these quotes.
If It Can't Happen, Use Assertions to Ensure That It Won't. Don't use assertions in place of real error handling. Assertions check for things that should never happen.
—Assertive Programming - The Pragmatic Programmer: From Journeyman to Master
Use error-handling code for conditions you expect to occur; use assertions for conditions that should never occur. Assertions check for conditions that should never occur. Error-handling code checks for off-nominal circumstances that might not occur very often, but that have been anticipated by the programmer who wrote the code and that need to be handled by the production code. Error handling typically checks for bad input data; assertions check for bugs in the code.
—Guidelines for Using Assertions - Code Complete: A Practical Handbook of Software Construction, Second Edition
There are many situations where it is good to use assertions, including:
- Internal Invariants
- Control-Flow Invariants
- Preconditions, Postconditions, and Class Invariants
There are also situations where you should not use them:
- Do not use assertions for argument checking in public methods. Argument checking is typically part of the published specifications (or contract) of a method, and these specifications must be obeyed whether assertions are enabled or disabled.
- Do not use assertions to do any work that your application requires for correct operation. Because assertions may be disabled, programs must not assume that the boolean expression contained in an assertion will be evaluated.
Therefore, I do not recommend you to use assertions in public APIs. Well-documented Errors are better.
Now let's see real world examples.
mapbox-gl-js uses assert and unassertify for enforcing internal invariants.
choo, sturdy frontend framework, uses unassertify for optimization.
choo author yoshua also wrote a tiny guide to non fancy, high-value Node.js things
It's generally a good idea to validate assumptions you make. This helps catch mistakes early and makes fixing them easier later on. I like using Node's built-in assert() package for this. Got an input type you want to validate? Assert it. Expect certain config values to exist? Assert it. Because I use it in all my packages, having an extra compile check for static types doesn't make sense for me. When deploying production code unassertify removes the extra checks.
If you have any questions, please feel free to ask me again. Thanks!
I'm already planning for quite some time to practice to code with assertions to later use unassert to get rid of them.
Currently I imagine, that in an ideal scenario, i want to remove all uses
assert
but maybe not the ones that are exposes as an API to users. Given valid inputs to whatever the API is, all internal libraries should work correctly, because of assert, but given incorrect API inputs, things might break when asserts are removed. But then again - even if only a single assert remains, it will pull in assert as a dependency, which is not really desirable when using the result in the browser.Is that correct?
Can you recommend some tutorials/howtos and/or nice examples how to get started?