Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to use unassert? #10

Open
serapath opened this issue Jan 18, 2017 · 1 comment
Open

How to use unassert? #10

serapath opened this issue Jan 18, 2017 · 1 comment

Comments

@serapath
Copy link

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?

@twada
Copy link
Member

twada commented Jan 19, 2017

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.

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.

Programming With Assertions - Java Programming Language

Therefore, I do not recommend you to use assertions in public APIs. Well-documented Errors are better.

unassert users

Now let's see real world examples.

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants