Closed (won't fix)
Project:
Services
Version:
6.x-3.x-dev
Component:
Code
Priority:
Minor
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
26 Oct 2011 at 14:44 UTC
Updated:
2 Mar 2012 at 21:35 UTC
I will try to add a few of these issues to try and give programmers better feedback to get services working faster.
Issue here is to parse the resource hook (hook_services_resources) and spit out debug messages on failure of parsing. Since no feedback is given on improper syntax.
Will have to check name exists for the group of resources.
Will check if function callback available and found.
Will check arguments to see if they match up and are syntactically correct.
Will check access arguments to make sure they will work.
And more if you can add it.
Thanks guys.
Comments
Comment #1
marcingy commentedI am really against this idea as it will cause code bloat and goes against normal drupal practice.
Comment #2
coolestdude1 commentedI agree and disagree with this statement or at least parts of it.
Obviously it will add more code and I am not saying that this will be easy but properly handling errors in a module is just good practice. No where in the coding standards have I found checking for syntax to be against drupal practice actually completely the opposite is true.
If the code throws no errors because you decided to not check for syntax then it is the responsibility of the module maintainers to add those necessary checks. Being a coder myself the whole point of proper error checking is to debug faster. Sadly this leads to programmer burnout and can often make people frustrated. I was myself in this situation yesterday on IRC. I am not looking to offend or even attack the maintainers in any way. I just want a better drupal just like every other person on here looking for answers.
I strongly oppose just doing an exit every time an uncaught exception happens. This will in turn make the process of creating a service even longer and for maintainability this is not what we want.
Even if the error in the dblog just says check syntax and gives a link to a help article that would be miles above what we have today.
Comment #3
marcingy commentedDrupal does not do this any where in the system - pdo throughs fatal errors if syntax is wrong, it doesn't check types etc it just errors that is something that ships in core. I am pretty much inclined to mark this as won't fix but want other maintainers to chip in.
Comment #4
coolestdude1 commentedI disagree if that was true then I would actually see errors in the error log for all these functions that I have been calling incorrectly. Even if drupal threw an error that would be miles above what we have right now which is a silent fail. And a silent fail pisses people off more than a verbose failure but anything at all would be great. Thanks for your time man I know I am posting a bunch today. :)
Comment #5
grimbones commentedI would have to side with coolestdude1 on this one. Even if Drupal threw an error it wouldn't be descriptive or helpful it would just tell you that something is wrong. There are many modules that do good error reporting above and beyond what core does. Who doesn't check input? An example of good error reporting is the Node Import module. When a csv is uploaded it checks to make sure that the information in the document is correct before it submits it to Drupal and then it gives you a detailed report back of exactly where the problem is. Good error reporting will also cut down on issues that you have to deal with, so it saves you time in the long run.
http://drupal.org/project/node_import
Comment #6
marcingy commentedI think the best way to approach this is to say create a patch and it will be reviewed, even patches for specific areas of the system that need error handling. Without such a patch it is highly unlikely that error handling will be introduced any time mainly because there isn't a desire to add it among the maintainers.
Comment #7
marcingy commented