Download the PHP package lucinda/errors without Composer
On this page you can find all versions of the php package lucinda/errors. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Download lucinda/errors
More information about lucinda/errors
Files in lucinda/errors
Package errors
Short Description Bootstraps errors and handles them via reporters and renderers
License MIT
Homepage http://www.lucinda-framework.com/errors-api
FAQ
Example:
In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
- Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
- To use Composer is sometimes complicated. Especially for beginners.
- Composer needs much resources. Sometimes they are not available on a simple webspace.
- If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
- Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Informations about the package errors
php-errors-api
Like any other scripting language, PHP has two types of errors:
- syntax errors: language errors in your script that cause immediate failure. These errors cause script to exit immediately without going through a listenable shutdown phase. Thankfully though, they are easily dealt with by using a modern IDE (such as Eclipse) that highlights syntax errors.
- execution errors: errors that appear while a correctly written script is executed. PHP recognizes following types of execution errors:
- fatal errors: self-handled errors causing script to exit, while a message is displayed and a log entry is recorded (eg: a non-existent method is called)
- non-fatal errors: self-handled errors causing script to continue execution, while a message is displayed and a log entry is recorded (eg: a non-existent entry in an array is accessed)
- exceptions: user-handled errors that can be manually thrown and handled
Ideally, errors should have thrown an exception able to be user-handled (to make the the whole process of error handling controllable from a single point), but up until version 7.0 users had to manually direct self-handled errors & uncaught exceptions to user-defined exceptions in order to achieve a single point of control for errors flow. This functionality, primitive as it is, provides a hook for an AOP layer that non-destructively listens to application for cross-cutting concerns (errors), keeping all other components strictly dedicated to their purpose and oblivious of error handling.
ErrorsAPI provides a thin layer of abstraction (skeleton) for unified error handling (redirecting all uncaught error to an errors' front controller). Its control point is the ErrorHandler class, able to register reporters (storage mediums in which error will be logged into) and renderer (entity that will perform response back to caller), then handle any exception by delegating to registered reporters and renderer. In order to handle PHP execution errors as well, API turns on reporting for all PHP errors then redirects them to a PHPException class, via native set_error_handler & register_shutdown_function. From that moment on, every PHP execution error will automatically throw a PHPException, which is then delegated to an ErrorHandler instance that must be registered beforehand.
More information here:
http://www.lucinda-framework.com/errors-api
