PHPackages                             smuuf/better-php-exceptions - 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. [Debugging &amp; Profiling](/categories/debugging)
4. /
5. smuuf/better-php-exceptions

ActiveLibrary[Debugging &amp; Profiling](/categories/debugging)

smuuf/better-php-exceptions
===========================

Package providing better and improved PHP exceptions.

0.2.1(5y ago)16632↑1400%MITPHPPHP ^7.4|^8.0

Since Dec 19Pushed 5y ago1 watchersCompare

[ Source](https://github.com/smuuf/better-php-exceptions)[ Packagist](https://packagist.org/packages/smuuf/better-php-exceptions)[ RSS](/packages/smuuf-better-php-exceptions/feed)WikiDiscussions master Synced 1mo ago

READMEChangelog (3)Dependencies (2)Versions (4)Used By (0)

Better PHP Exceptions
=====================

[](#better-php-exceptions)

What is it about?
-----------------

[](#what-is-it-about)

This small project aims to provide **improved user/developer experience** for PHP developers working with native PHP exceptions *(thrown by the PHP interpreter itself in various situations)*.

*Better PHP Exceptions* can be created from native exceptions via **unified interface**:

```
use \Smuuf\BetterExceptions\BetterException;

try {
	...
} catch (\Throwable $ex) {
	$better = BetterException::from($ex);
	...
}
```

As an example scenario, both `PHP 7.*` and `PHP 8.0` throw `TypeError` exceptions in three distinct scenarios:

> There are three scenarios where a TypeError may be thrown. The first is where the argument type being passed to a function does not match its corresponding declared parameter type. The second is where a value being returned from a function does not match the declared function return type. The third is where an invalid number of arguments are passed to a built-in PHP function (strict mode only).

~

Sadly, PHP or the `TypeError` itself does *not* provide any additional information about the types expected, types passed/returned, or at which position the passed wrong type was present during invocation.

*Was it an argument type error? A return type error? What was it...!?*

**This information is present only in the exception message and it takes an extra parsing effort to get it.** Not to mention the fact that the format of these messages changed from `PHP 7` to `PHP 8` and thus need different parsing rules...

**This is where *Better PHP Exceptions* come in.**

Example
-------

[](#example)

```
