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

Option to fail silently when resource optional but valid attr is not set #6

Closed
andreiavram opened this Issue Feb 1, 2014 · 4 comments

Comments

2 participants
@andreiavram
Contributor

andreiavram commented Feb 1, 2014

Currently, if trying to access resource.attr when the attr is not set on the resource will raise an exception.

This is useful when trying to access an invalid attribute for a given resource, like "issue.date_due" instead of "issue.due_date". But this exception is also thrown up when the given attr is not set on the resource, even though it is valid for the given resource (for example, if due date is not set, issue.due_date will raise an exception.

One could always wrap code in try catch statements, but this might be impractical, especially in contexts when this is not as easy to do (for example, in django template code)

@ghost ghost assigned maxtepkeev Feb 1, 2014

@maxtepkeev

This comment has been minimized.

Owner

maxtepkeev commented Feb 1, 2014

Only two things come to my mind at the moment:

  1. We can hardcode all the valid attributes for each resource and then check if a requested attribute is in the list of valid attributes we fail silently. But this is what I always trying to avoid, for example if a new version of Redmine will be released and there will be some new fields we will have to add them to this list of valid attributes every time. Not good.
  2. Add a global or per resource option whether to raise an exception if an unset attribute is requested. This will solve this problem but it may give you another problems, e.g. imagine you mistyped a resource attribute (issue.subjekt) and it won't tell you anything about it and you won't get any subject of course. Not good also.

What do you think ?

@andreiavram

This comment has been minimized.

Contributor

andreiavram commented Feb 1, 2014

I agree that a solution to such a problem is not available without some sort of compromise. I also agree that the first solution you listed would be a support nightmare.

But the second, if it's given as a constructor parameter for the main Redmine object or wherever, is a "risk" the user takes - just like setting https request verification to False - I find this less of a problem.

I hit this problem while listing issues inside a template, some had an optional field set, some didn't. For this case, a different kind of compromise can be imagined: each Redmine session could infer existing field names for the current connection for each resource type, and return None in getattr whenever we know this field existed in at least one resource of this type, not necessarily the current one.

This will at least give the connector knowledge of the fields that it received up to one point. These may very well not be all fields, but it might be a step forward (also, at least in some usecases, an user is less likely to request attrs that none of the resources he requested has, right?)

@maxtepkeev

This comment has been minimized.

Owner

maxtepkeev commented Feb 1, 2014

Okay, you convinced me ;-)

I like your idea about per session field names memorization, but I don't think it will work, because if a first object in a queue won't have a requested field an exception will be thrown anyway.

So I believe the option 2 is the best we can do. I added the raise_attr_exception kwarg to Redmine object which defaults to True to not break existing code. See 11d3f5e. You can set it to False to completely disable the ResourceAttrError or you can give it a list or tuple of resource class names and it will continue to raise an exception only for this types of resources. All other resources will return None and remain silent. Details can be found in the documentation.

Please reopen if anything isn't working like it should. Thanks.

@maxtepkeev maxtepkeev closed this Feb 1, 2014

@andreiavram

This comment has been minimized.

Contributor

andreiavram commented Feb 1, 2014

Great, thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment