Download the PHP package granam/exception-hierarchy without Composer
On this page you can find all versions of the php package granam/exception-hierarchy. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
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 exception-hierarchy
Philosophy of exception hierarchy is kind of you need to know.
It is important to know what happened. And it happens...
The system fails. Something exceptionable occurs.
Take extra care to get as much description of a problem as possible.
The good way how to achieve that is keep exceptions hierarchy clean and clear.
- follow the project structure.
- make a root exception marker as an interface.
- include this interface in every exception you produce.
- by that, anyone can catch exceptions from your project in his project, by a single catch
- learn the difference between logic and runtime exception
- the base distinction is the logic exception can be detected at compile time (for easy example by IDE), the runtime exception can not - it can occurs only in some combination of data and environment
- logic exception should occurs if definitely there is an mistake in use of the application
- that exception tells you: you are using something bad, fix it
- runtime exception is everything else of course
- that means: your application is not so robust as should be - fix it or ignore for eternity
- is it so simple, with clean borders?
- of course not
- but like that you can catch all the logic exceptions into folder PersistentBugs and runtime ones into BulletproofFailures
In short
Runtime exception should occurs if something is wrong from outside.
Logic exception should occurs if something is wrong from inside.
Example of use of Logic and Runtime exception
You built an e-shop with an API.
Your frontend application sends to the API a request for new customer:
- email: dontbotherme
That is not valid email for sure. The frontend check failed and now you are forced to handle that failure.
So lets throw some Runtime (like InvalidEmailFormat) exception somewhere inside your code.
Your API of course should catch such exception and returns 400 Bad Request (and descriptive error message).
In another case your application calculates price of an purchase, including discount coupon, volume discount, loyalty discount and... voala, the final price is negative!
That is fatal error for sure, originating inside your application. Logic exception (like FinalPriceZeroOrLesser) should be thrown.
The API of course catch that exception and turn it into response 500 Server error (and log that exception for asap fix!) .
