-
Notifications
You must be signed in to change notification settings - Fork 481
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Request: Catching errors #52
Comments
I've actually been thinking about this for a while. Rather than return errors like described above, I'd much rather throw exceptions:
The reason I haven't implemented it yet is because I'm worried it will be a culture shock for a lot of CI devs (CI isn't exactly an exception-conducive environment). The benefits of using exceptions are many: errors can be selectively ignored, easily logged, caught and re-thrown with new messages, reported to other parts of the application, not to mention all the extra context you get (stack traces). I'd certainly favour an exception-based system, but what does the community think? |
@jamierumbelow I'd be interested in seeing how the exceptions approach would play out. Especially after reading your book on API design, I'm beginning to see the power in throwing exceptions. It might be helpful to see this approach in more detail, perhaps in a feature branch, so that the community could better understand how this method would effect things. Personally, my only concern with this approach is this seems like it would add a ton of lines to the code - adding try/ catch/ catch lines to many of the model functions (ie: get, get_all, get_by, get_many_by, insert, update, delete). And this could, as you pointed out, be a bit of a shock. It could also make the code harder to follow. |
Throwing an exception is indeed much more powerful and a beautiful way of handling, well, exceptions. However my concern is also that it would add a lot of extra code. But I have only played with exceptions so there might be a nice way of putting standard catchers in the base model so that one can either let the standard catcher take care of exceptions or write code to catch them. But I guess that the default catcher for all uncaught exceptions should realy be in CI. |
Using the MY_Controller from Jamie I think you could just put the try/catch around the call_user_func function and do it that way. It would be hard to control on an error-by-error basis though. |
I'd rather not tie users into using MY_Controller as well as MY_Model... the two should be usable independently. There are a few good benefits to forcing the usage of exceptions:
The cons:
Perhaps a way of disabling exceptions if you so wish? The exception system would almost certainly be implemented as observers, much like how relationships work. We could add a boolean to the class to disable exceptions if you weren't interested.
|
I definitely think that allowing them to turn it off would be the best way of handling it. |
If anyone fancies implementing this, be my guest. I'll get to it soon but am far too busy right now! |
+1 for for being able to turn it on and off. |
👍 looking forward to this. I was just thinking about how to properly handle errors with the stuff I've learned from volumes 1 and 2. |
I'm assuming that means nobody wants to implement it.... ;) |
hmm, well, I might just give it a shot ... |
How errors are handled for a model will be set in
by setting it to '' (default), 'exception', 'show' or 'log'. Error handling can also temporarily be set to something else with these calls:
To catch errors there will be six triggers. The first three can be combined, the last three are combinations.
For each there is also a default error message. Example use:
|
I really like that setup. Easy to implement as a chain and allows you to |
I need some way of protecting my site from database errors.
|
Without modifying the code base, you could extend |
I guess i need to clarify. It is not the data i expect errors from (that is handled just fine by validation) |
You could run a It won't fix the error, but it will allow you to 'catch' the error and handle it as you need, as opposed to falling back on the system or language erorrs. |
No, that is my point! No errors are thrown! I do not see how to get my exception without modifying the code
Before modification
|
@omegasteffy Unfortunately, I never got round to implementing an exceptions-based error handling system, even though this was my intention. Feel free to modify the core code as per the above suggestion and submit a pull request. |
I will consider to do so. However I am not certain the exception-based approach is needed. My problem is that there is no error handling for dB-connection failure... or rather i do not see how. |
"How to use throw exception in mysql database connect"
Alternatively, http://stackoverflow.com/a/9836807
Or, To hide the PHP Error, use the http://stackoverflow.com/a/6121357
|
I will look into implementing an exceptions-based error handling system, also. |
Many lines of code would be saved if we could catch simple errors with the base model and have an error message echoed and/or logged. You know all those infrequent errors that you want to check for but don't want to make a pretty user friendly interface for handling since it's broke and any how only the man in charge can fix it. Like this:
->on_error('Foobar missing.')
->get_all(...);
->on_error('Multiple Foobars matching criteria.')
->get_one(...);
Could even have a default error message so that just this would do the trick:
->on_error()
->get_all(...);
Brilliant or simply stupid?
The text was updated successfully, but these errors were encountered: