[
https://issues.apache.org/jira/browse/LANG-701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14259129#comment-14259129
]
Benedikt Ritter commented on LANG-701:
--------------------------------------
Hello [~jamessawle],
I like your enthusiasm :)
{quote}
I will remove the check on the message for now, but would like to create and
issue for adding them to the public API as can be as important as the type of
exception, especially when generic exception types are used. Even if we do not
publicly expose the messages, the changes should be considered regression
unless consciously considered.
{quote}
I don't understand what you're trying to achieve. Should we never change
exception messages once we have released them? How do we make sure this doesn't
happen? For API changes we use clirr. I'm not aware of of tool that can do the
same think like clirr does for messages of exceptions thrown from APIs.
Relying on exception messages is bad practice. I don't see a reason to impose
yet another restriction on how we can evolve our libraries, just to make sure
bad code won't break. My feeling it, that we should invest our energy into more
important things (like bugfixes and new features).
{quote}
I would also like to keep the ExpectedException within the pull request as it
is the recommended standard for JUnit over the annotation method. Should we not
use best practice for one part as not the standard across the rest of the API,
especially as it is an implementation detail?
{quote}
I've only found https://github.com/junit-team/junit/wiki/Exception-testing
which says that annotation based exception testing is okay for simple use
cases. At the moment we just have a simple use case, because we're only
interested in the type of exception. Can you please point me to the resource
you have taken this recommendation from?
I'd rather like to see this PR without the ExpectedExcetion. If you really want
to go that way, you should bring this up on the dev ML and here what other devs
think about this.
bq. I will also make the change to remove the dependency on Java 7 libraries as
well as the use of spaces instead of tabs.
Thank you and keep up the good work! :)
> StringUtils join with var args
> ------------------------------
>
> Key: LANG-701
> URL: https://issues.apache.org/jira/browse/LANG-701
> Project: Commons Lang
> Issue Type: New Feature
> Components: lang.*
> Reporter: Gabriele Kahlout
> Priority: Minor
> Fix For: Review Patch
>
> Attachments: VarArgJoinTest.java
>
>
> {code:java}
> final String apple = "apple";
> final String banana = "banana";
> final String orange = "orange";
> final String expected = apple + SPACE + banana + SPACE + orange;
> final String actual = join(SPACE, apple, banana, orange);
> final int expLength = expected.length();
> final int actLength = actual.length();
> assertEquals(expLength, actLength);
> assertEquals(expected, actual);
> {code}
> I missed the functionality of joining strings with the space separator in one
> line. BTW, why space ' ' not a constant field anywhere?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
