Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
From: iilyak <git@git.apache.org>
To: dev@couchdb.apache.org
Reply-To: dev@couchdb.apache.org
References: <git-pr-26-couchdb-chttpd@git.apache.org>
In-Reply-To: <git-pr-26-couchdb-chttpd@git.apache.org>
Subject: [GitHub] couchdb-chttpd pull request: Return {error,
 Reason} for illegal_da...
Content-Type: text/plain
Message-Id: <20150324133646.73EB5E0AB7@git1-us-west.apache.org>
Date: Tue, 24 Mar 2015 13:36:46 +0000 (UTC)

Github user iilyak commented on the pull request:

    https://github.com/apache/couchdb-chttpd/pull/26#issuecomment-85499451
  
    Here is the reason for the change https://github.com/iilyak/couchdb-couch/commit/0e01a33cc6443f0690cc5f2460c0240b64eda335. However I did close the main PR. The rationale for changing message text was discussed in closed PR I linked above. 
    
    > @kxepal: In case of db name validation customization this error message shouldn't be defined here since the requirements for the name could be different.
    
    Another orphan PR related to the issue: https://github.com/apache/couchdb-fabric/pull/14
    
    The code duplication need to be eliminated anyway regardless of configurable dbname validator feature.
    Also I do believe all errors need to be `{error, Reason}` across the system. Since it allows you to wrap functions when you need it without knowing all possible errors that wrapped function could return. You just handle `{error, Reason}` do error case logic and bubble `{error, Reason}` up.   
    
    I can create a new main PR which would just implement couch_db:validate_dbname and changes the error `{error, illegal_database_name, DbName}` -> `{error, {illegal_database_name, DbName}}`. I could create new jira issue with following description: `Remove code duplication in dbname validation`. If I go with second approach I would need to rewrite history for this PR to refer to different jira issue. I could create 2 different JIRA issues one for {error, Reason} and another one for code duplication.
    
    Please advise what would be the better (I prefer second). 


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---