You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@tapestry.apache.org by "Howard M. Lewis Ship (JIRA)" <ji...@apache.org> on 2010/02/24 23:35:28 UTC

[jira] Created: (TAP5-1032) Reporting validation exceptions by throwing an exception is bad form: allow for returning a value instead

Reporting validation exceptions by throwing an exception is bad form: allow for returning a value instead
---------------------------------------------------------------------------------------------------------

                 Key: TAP5-1032
                 URL: https://issues.apache.org/jira/browse/TAP5-1032
             Project: Tapestry 5
          Issue Type: Bug
          Components: tapestry-core
    Affects Versions: 5.2.0
            Reporter: Howard M. Lewis Ship


>From the Dept. Of "We did this in T4 and didn't know it was brain damaged then." ... various APIs related to translation and validation work by throwing a ValidationException which is nothing more than a wrapper around an error message string. It would be nice to allow, in some compatible way, allow methods to simply return the exception, or even just the string for the exception, rather than throwing an exception, which is very inefficient.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Commented: (TAP5-1032) Reporting validation exceptions by throwing an exception is bad form: allow for returning a value instead

Posted by "Thiago H. de Paula Figueiredo (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/TAP5-1032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12838051#action_12838051 ] 

Thiago H. de Paula Figueiredo commented on TAP5-1032:
-----------------------------------------------------

Couldn't we use the approach of creating a Translator and Validator subinterfaces and adding the improved method signatures on them?

> Reporting validation exceptions by throwing an exception is bad form: allow for returning a value instead
> ---------------------------------------------------------------------------------------------------------
>
>                 Key: TAP5-1032
>                 URL: https://issues.apache.org/jira/browse/TAP5-1032
>             Project: Tapestry 5
>          Issue Type: Bug
>          Components: tapestry-core
>    Affects Versions: 5.2.0
>            Reporter: Howard M. Lewis Ship
>
> From the Dept. Of "We did this in T4 and didn't know it was brain damaged then." ... various APIs related to translation and validation work by throwing a ValidationException which is nothing more than a wrapper around an error message string. It would be nice to allow, in some compatible way, allow methods to simply return the exception, or even just the string for the exception, rather than throwing an exception, which is very inefficient.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Commented: (TAP5-1032) Reporting validation exceptions by throwing an exception is bad form: allow for returning a value instead

Posted by "Thiago H. de Paula Figueiredo (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/TAP5-1032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12838051#action_12838051 ] 

Thiago H. de Paula Figueiredo commented on TAP5-1032:
-----------------------------------------------------

Couldn't we use the approach of creating a Translator and Validator subinterfaces and adding the improved method signatures on them?

> Reporting validation exceptions by throwing an exception is bad form: allow for returning a value instead
> ---------------------------------------------------------------------------------------------------------
>
>                 Key: TAP5-1032
>                 URL: https://issues.apache.org/jira/browse/TAP5-1032
>             Project: Tapestry 5
>          Issue Type: Bug
>          Components: tapestry-core
>    Affects Versions: 5.2.0
>            Reporter: Howard M. Lewis Ship
>
> From the Dept. Of "We did this in T4 and didn't know it was brain damaged then." ... various APIs related to translation and validation work by throwing a ValidationException which is nothing more than a wrapper around an error message string. It would be nice to allow, in some compatible way, allow methods to simply return the exception, or even just the string for the exception, rather than throwing an exception, which is very inefficient.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Commented: (TAP5-1032) Reporting validation exceptions by throwing an exception is bad form: allow for returning a value instead

Posted by "Howard M. Lewis Ship (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/TAP5-1032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12838036#action_12838036 ] 

Howard M. Lewis Ship commented on TAP5-1032:
--------------------------------------------

Hm. The APIs are entrenched, and they make sense in some circumstances, i.e.:

public interface Translator<T> {
 ...
  T parseClient(Field field, String clientValue, String message) throws ValidationException;
 ...

Once you have that, it's nice for the Validator methods to throw the exception (for consistency) even they they are void methods.  In addition, the horse has left the barn in some ways w.r.t. changing such a central API.

> Reporting validation exceptions by throwing an exception is bad form: allow for returning a value instead
> ---------------------------------------------------------------------------------------------------------
>
>                 Key: TAP5-1032
>                 URL: https://issues.apache.org/jira/browse/TAP5-1032
>             Project: Tapestry 5
>          Issue Type: Bug
>          Components: tapestry-core
>    Affects Versions: 5.2.0
>            Reporter: Howard M. Lewis Ship
>
> From the Dept. Of "We did this in T4 and didn't know it was brain damaged then." ... various APIs related to translation and validation work by throwing a ValidationException which is nothing more than a wrapper around an error message string. It would be nice to allow, in some compatible way, allow methods to simply return the exception, or even just the string for the exception, rather than throwing an exception, which is very inefficient.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Closed: (TAP5-1032) Reporting validation exceptions by throwing an exception is bad form: allow for returning a value instead

Posted by "Howard M. Lewis Ship (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/TAP5-1032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard M. Lewis Ship closed TAP5-1032.
--------------------------------------

    Resolution: Invalid

Basically, we are using exceptions as a form of covariant return value; ideally we should have a different API where the methods are void but produce side effects by invoking methods on an object passed in (one method for a succesfully translated value, another method when there's an error). For the meantime, we'll have to leave it as it is.

> Reporting validation exceptions by throwing an exception is bad form: allow for returning a value instead
> ---------------------------------------------------------------------------------------------------------
>
>                 Key: TAP5-1032
>                 URL: https://issues.apache.org/jira/browse/TAP5-1032
>             Project: Tapestry 5
>          Issue Type: Bug
>          Components: tapestry-core
>    Affects Versions: 5.2.0
>            Reporter: Howard M. Lewis Ship
>
> From the Dept. Of "We did this in T4 and didn't know it was brain damaged then." ... various APIs related to translation and validation work by throwing a ValidationException which is nothing more than a wrapper around an error message string. It would be nice to allow, in some compatible way, allow methods to simply return the exception, or even just the string for the exception, rather than throwing an exception, which is very inefficient.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Closed: (TAP5-1032) Reporting validation exceptions by throwing an exception is bad form: allow for returning a value instead

Posted by "Howard M. Lewis Ship (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/TAP5-1032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard M. Lewis Ship closed TAP5-1032.
--------------------------------------

    Resolution: Invalid

Basically, we are using exceptions as a form of covariant return value; ideally we should have a different API where the methods are void but produce side effects by invoking methods on an object passed in (one method for a succesfully translated value, another method when there's an error). For the meantime, we'll have to leave it as it is.

> Reporting validation exceptions by throwing an exception is bad form: allow for returning a value instead
> ---------------------------------------------------------------------------------------------------------
>
>                 Key: TAP5-1032
>                 URL: https://issues.apache.org/jira/browse/TAP5-1032
>             Project: Tapestry 5
>          Issue Type: Bug
>          Components: tapestry-core
>    Affects Versions: 5.2.0
>            Reporter: Howard M. Lewis Ship
>
> From the Dept. Of "We did this in T4 and didn't know it was brain damaged then." ... various APIs related to translation and validation work by throwing a ValidationException which is nothing more than a wrapper around an error message string. It would be nice to allow, in some compatible way, allow methods to simply return the exception, or even just the string for the exception, rather than throwing an exception, which is very inefficient.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Commented: (TAP5-1032) Reporting validation exceptions by throwing an exception is bad form: allow for returning a value instead

Posted by "Howard M. Lewis Ship (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/TAP5-1032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12838036#action_12838036 ] 

Howard M. Lewis Ship commented on TAP5-1032:
--------------------------------------------

Hm. The APIs are entrenched, and they make sense in some circumstances, i.e.:

public interface Translator<T> {
 ...
  T parseClient(Field field, String clientValue, String message) throws ValidationException;
 ...

Once you have that, it's nice for the Validator methods to throw the exception (for consistency) even they they are void methods.  In addition, the horse has left the barn in some ways w.r.t. changing such a central API.

> Reporting validation exceptions by throwing an exception is bad form: allow for returning a value instead
> ---------------------------------------------------------------------------------------------------------
>
>                 Key: TAP5-1032
>                 URL: https://issues.apache.org/jira/browse/TAP5-1032
>             Project: Tapestry 5
>          Issue Type: Bug
>          Components: tapestry-core
>    Affects Versions: 5.2.0
>            Reporter: Howard M. Lewis Ship
>
> From the Dept. Of "We did this in T4 and didn't know it was brain damaged then." ... various APIs related to translation and validation work by throwing a ValidationException which is nothing more than a wrapper around an error message string. It would be nice to allow, in some compatible way, allow methods to simply return the exception, or even just the string for the exception, rather than throwing an exception, which is very inefficient.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.