PHPackages                             mixteer/reshi - PHPackages - PHPackages  [Skip to content](#main-content)[PHPackages](/)[Directory](/)[Categories](/categories)[Trending](/trending)[Leaderboard](/leaderboard)[Changelog](/changelog)[Analyze](/analyze)[Collections](/collections)[Log in](/login)[Sign up](/register)

1. [Directory](/)
2. /
3. [Testing & Quality](/categories/testing)
4. /
5. mixteer/reshi

ActiveLibrary[Testing & Quality](/categories/testing)

mixteer/reshi
=============

Reshi libray, an assertion library.

0.1.0(11y ago)220MITPHPPHP >=5.3.0

Since Jan 24Pushed 11y ago2 watchersCompare

[ Source](https://github.com/Mixteer/reshi)[ Packagist](https://packagist.org/packages/mixteer/reshi)[ Docs](https://github.com/mixteer/reshi)[ RSS](/packages/mixteer-reshi/feed)WikiDiscussions master Synced 2d ago

READMEChangelog (1)DependenciesVersions (2)Used By (0)

Reshi - facilitating assertive programming
==========================================

[](#reshi---facilitating-assertive-programming)

> "If It Can't Happen, Use Assertions to Ensure That It Won't" -- A. Hunt and D. Thomas in The Pragmatic Programmer.

Reshi is an assertion library that it meant to check constraints you impose on say function input parameters. The idea behind it is that of assertive programming as found in **Section 23, Chapter 4 of the book The Pragmatic Programmer.**

You use Reshi to make sure that event that you think will never occur doesn't cause damage in case it does occur. See Section 22 Dead programs tell no lies of the same chapter.

Install
-------

[](#install)

The library is available on [packagist](https://packagist.org/) and installable via [composer](http://getcomposer.org).

```
{
    "require": {
        "mixteer/reshi": "0.1.*"
    }
}
```

Concepts
--------

[](#concepts)

The 3 main concepts about the why and how of this library are derived from **The Pragmatic Programmer** in Chapter 4:

1. *Assertive programming* - you use assertions to make sure things that shouldn't normally happen are guarded against just in case they do happen.
2. *Dead programs tell no lies* - if an assertion fails, the library triggers a `E_USER_ERROR` error which ends the program immediately. You'll have an error handler which should log this error as it will contain the details of which assertion failed and details like file name and line number.
3. *Use exceptions for exceptional cases* - the library doesn't throw an exception when the assertion fails simply to help avoid someone catching the exception, doing nothing with it and hence the program might continue. Yes, errors can be converted into exceptions but going to all that trouble assumes you have a good idea and fair reason for doing so. Note that while assertions help guard against rare bad events, those are not part of your business logic so use of exceptions here is not a good idea. But when the library methods are given wrong parameters, the will emit exceptions because that's part of their business logic.

Usage
-----

[](#usage)

Using the library is fairly simple:

```