On Sat, 28 Aug 2004, matthew.hawthorne wrote:
IMO, copy-paste reuse is the worst offense that a programmer can commit.
I agree that it's bad news.
But, I think the worst offense is this:
try {
// ...
} catch (Exception e) {
return null;
}
(shudder)
How lucky you've been.
Leo,
is this something we should be fixing in the site plugin back in Maven?
On 28 Aug 2004 21:50:26 -, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
leosutic2004/08/28 14:50:26
Modified:attributes maven.xml windeploysite.cmd
Log:
Fixed windows deployment of website.
matthew.hawthorne wrote:
I see your point, but keep in mind that this was done to make the lives
of the users easier. Forcing a user to include a huge [collections] jar
for a project that only uses 1 or 2 classes from it doesn't seem
practical to me.
Well, there's always the tradeoff between
1.
dion2004/08/29 04:47:53
Modified:jelly/src/test/org/apache/commons/jelly/expression
TestExpressions.java
Log:
Failing test for JELLY-87
Revision ChangesPath
1.12 +1 -0
dion2004/08/29 06:20:54
Modified:jelly/src/java/org/apache/commons/jelly/expression
CompositeExpression.java
Log:
Formatting
Revision ChangesPath
1.10 +70 -114
dion2004/08/29 06:25:42
Modified:jelly/src/test/org/apache/commons/jelly/expression
TestExpressions.java
Log:
Add some more stuff that should work and comment out known issues
Revision ChangesPath
1.13 +13 -14
+---+
| Bugzilla Bug ID |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned
--- matthew.hawthorne [EMAIL PROTECTED] wrote:
I agree that it's bad news.
But, I think the worst offense is this:
try {
// ...
} catch (Exception e) {
return null;
}
(shudder)
I've seen plenty of this to; it's truly horrifying :-).
try {
// ...
} catch
--- Henri Yandell [EMAIL PROTECTED] wrote:
On Sat, 28 Aug 2004, matthew.hawthorne wrote:
IMO, copy-paste reuse is the worst offense that a programmer can
commit.
I agree that it's bad news.
But, I think the worst offense is this:
try {
// ...
} catch (Exception e)
David Graham wrote:
--- Henri Yandell [EMAIL PROTECTED] wrote:
On Sat, 28 Aug 2004, matthew.hawthorne wrote:
IMO, copy-paste reuse is the worst offense that a programmer can
commit.
I agree that it's bad news.
But, I think the worst offense is this:
try {
// ...
} catch
MUCH worse would be returning from a 'finally' clause, which can cause
unexpected control flow behaviour. See The Java Hall of Shame:
http://www.cs.arizona.edu/sumatra/hallofshame/
and also The Lost Exception in Bruce Eckel's Thinking in Java.
--
Martin Cooper
On Sun, 29 Aug 2004 02:12:37
rdonkin 2004/08/29 11:05:27
Modified:digester Tag: RELEASE_DIGESTER_1_6_0_BRANCH
RELEASE-NOTES.txt
Log:
Updated release notes to reflect planned release.
Revision ChangesPath
No revision
No revision
1.13.2.1
rdonkin 2004/08/29 11:05:55
Modified:digester Tag: RELEASE_DIGESTER_1_6_0_BRANCH STATUS.html
Log:
Updated status to reflect planned release.
Revision ChangesPath
No revision
No revision
1.11.6.1 +15 -39
rdonkin 2004/08/29 11:15:19
Added: digester/src/examples/rss Tag: RELEASE_DIGESTER_1_6_0_BRANCH
.cvsignore
Log:
Ignore build related files and directories
Revision ChangesPath
No revision
No revision
rdonkin 2004/08/29 11:16:06
Added: digester/src/examples/rss Tag: RELEASE_DIGESTER_1_6_0_BRANCH
build.properties.sample
Log:
Sample properties file for the build
Revision ChangesPath
No revision
No revision
rdonkin 2004/08/29 11:16:46
Modified:digester/src/examples/rss Tag: RELEASE_DIGESTER_1_6_0_BRANCH
build.xml readme.txt
Log:
Tidied up build
Revision ChangesPath
No revision
No revision
1.1.2.2 +1 -6
Thanx for the reference, Martin. It is a hoot what people will do. I
am not immune, I am sure.
Michael
Martin Cooper wrote:
MUCH worse would be returning from a 'finally' clause, which can cause
unexpected control flow behaviour. See The Java Hall of Shame:
On Sun, 29 Aug 2004, Michael McGrady wrote:
Well, would
boolean dontAsk = false;
try {
} catch (Throwable t) {
dontAsk = true;
} finally {
if(dontAsk) System.exit(0);
}
be worse? LOL
Yes! It should clearly be System.exit(1)! That's *awful*!
--scott
rdonkin 2004/08/29 11:26:08
Modified:digester/src/examples/xmlrules/addressbook Tag:
RELEASE_DIGESTER_1_6_0_BRANCH example.xml
Log:
Corrected bad formed xml
Revision ChangesPath
No revision
No revision
rdonkin 2004/08/29 11:26:43
Modified:digester/src/examples/xmlrules/addressbook Tag:
RELEASE_DIGESTER_1_6_0_BRANCH build.xml
Log:
Tidied up build (a very little)
Revision ChangesPath
No revision
No revision
rdonkin 2004/08/29 11:27:30
Added: digester/src/examples/xmlrules/addressbook Tag:
RELEASE_DIGESTER_1_6_0_BRANCH .cvsignore
Log:
Ignore build files
Revision ChangesPath
No revision
No revision
1.1.2.1 +2
rdonkin 2004/08/29 11:28:01
Added: digester/src/examples/xmlrules/addressbook Tag:
RELEASE_DIGESTER_1_6_0_BRANCH
build.properties.sample
Log:
Sample build properties file
Revision ChangesPath
No revision
rdonkin 2004/08/29 11:30:44
Added: digester/src/examples/plugins/pipeline Tag:
RELEASE_DIGESTER_1_6_0_BRANCH .cvsignore
Log:
Ignore build products
Revision ChangesPath
No revision
No revision
1.1.2.1 +3
rdonkin 2004/08/29 11:31:42
Added: digester/src/examples/plugins/pipeline Tag:
RELEASE_DIGESTER_1_6_0_BRANCH
build.properties.sample
Log:
Sample build properties file
Revision ChangesPath
No revision
rdonkin 2004/08/29 11:37:45
Modified:digester/src/java/org/apache/commons/digester Tag:
RELEASE_DIGESTER_1_6_0_BRANCH package.html
Log:
Fixes to package documentation.
Revision ChangesPath
No revision
No
rdonkin 2004/08/29 11:40:06
Modified:digester/src/java/org/apache/commons/digester Tag:
RELEASE_DIGESTER_1_6_0_BRANCH package.html
Log:
Improved look
Revision ChangesPath
No revision
No revision
1.30.2.4 +5
rdonkin 2004/08/29 11:41:25
Modified:digester/src/java/org/apache/commons/digester/parser Tag:
RELEASE_DIGESTER_1_6_0_BRANCH package.html
Log:
Fixed typos
Revision ChangesPath
No revision
No revision
1.1.6.2
If we have not succeeded in keeping things simple, we are certainly
open to improving documentation and / or providing wrappers or
simplified interfaces. If you have specific examples / suggestions
for improvement, please share these. We want to make the package as
easy to use a possible,
The following comment has been added to this issue:
Author: dion gillard
Created: Sun, 29 Aug 2004 4:37 PM
Body:
There's a good reason for this: Jelly's support for ant variables currently only
allows them to be retrieved from the context, no further evaluation is done.
This is
The following comment has been added to this issue:
Author: dion gillard
Created: Sun, 29 Aug 2004 4:39 PM
Body:
FWIW, this is not a blocker for me for beta-4.
It seems that it is entirely a DOM4J issue.
-
View
dion2004/08/29 16:38:58
Modified:jelly/src/java/org/apache/commons/jelly/expression/jexl
JexlExpressionFactory.java
Log:
[,],( and ) are not part of a valid ant variable
Revision ChangesPath
1.18 +2 -2
The following issue has been updated:
Updater: dion gillard (mailto:[EMAIL PROTECTED])
Date: Sun, 29 Aug 2004 5:05 PM
Comment:
I think this should be done for beta4
Changes:
Fix Version changed to 1.0-beta-4
dion2004/08/29 17:10:29
Modified:jelly/src/test/org/apache/commons/jelly/core TestNewTag.java
Log:
Remove unused code
Revision ChangesPath
1.6 +1 -9
jakarta-commons/jelly/src/test/org/apache/commons/jelly/core/TestNewTag.java
Index: TestNewTag.java
Message:
The following issue has been re-assigned.
Assignee: dion gillard (mailto:[EMAIL PROTECTED])
-
View the issue:
http://issues.apache.org/jira/browse/JELLY-120
Here is an overview of the issue:
The following issue has been updated:
Updater: Hans Gilde (mailto:[EMAIL PROTECTED])
Date: Sun, 29 Aug 2004 5:32 PM
Comment:
cool, how about this one. It adds an option to ignore unknown properties. I figured
that subclasses of UseBean might want it to ignore unknown properties.
Message:
A new issue has been created in JIRA.
-
View the issue:
http://issues.apache.org/jira/browse/JELLY-122
Here is an overview of the issue:
-
The following issue has been updated:
Updater: Hans Gilde (mailto:[EMAIL PROTECTED])
Date: Sun, 29 Aug 2004 6:28 PM
Comment:
and the patch to fix it
Changes:
Attachment changed to component-clear-bean.txt
Well, I had a discussion with several collegues (type science users, we
went snorkeling) on several of these issues. The score of the day was
the idea that the simple linear LS regression was considered a
multvariate statistics.
Phil Steitz wrote:
Nothing has been put aside. We make decisions
dion2004/08/29 19:16:38
Modified:jelly/src/java/org/apache/commons/jelly JellyContext.java
Log:
Apply fix for Jelly-78
Revision ChangesPath
1.54 +7 -0
jakarta-commons/jelly/src/java/org/apache/commons/jelly/JellyContext.java
Index: JellyContext.java
The following issue has been updated:
Updater: dion gillard (mailto:[EMAIL PROTECTED])
Date: Sun, 29 Aug 2004 8:20 PM
Changes:
Fix Version changed to 1.0
Fix Version changed from 1.0-beta-4
Kim van der Linde wrote:
Well, I had a discussion with several collegues (type science users, we
went snorkeling) on several of these issues. The score of the day was
the idea that the simple linear LS regression was considered a
multvariate statistics.
So it should stay where it is.
Phil
Phil Steitz wrote:
Kim van der Linde wrote:
Well, I had a discussion with several collegues (type science users,
we went snorkeling) on several of these issues. The score of the day
was the idea that the simple linear LS regression was considered a
multvariate statistics.
So it should stay
If we get System.exit(0) when there is a problem or when these is not,
isn't that worse than System.exit(1) under the same conditions?
Michael
C. Scott Ananian wrote:
On Sun, 29 Aug 2004, Michael McGrady wrote:
Well, would
boolean dontAsk = false;
try {
} catch (Throwable t) {
Thanks Oleg,
Appreciate your bunch of random thoughts. We'll probably build a
source code converter utility here and send it along once we're happy
with it.
Fwiw, your luck (or our lack of luck) may have to do with the fact that
we use log4j natively; it's possible and plausible that mixed
44 matches
Mail list logo
