Skip to content

How to use unassert? #10

Open
Open

Description

@serapath

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?

Activity

  1. twada commented on Jan 19, 2017

    @twada
    Member

    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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions