Re: [jira] Commented: (DERBY-1438) Text written by SQLException.toString differs between client and embedded driver
Thanks, Knut. I was unaware that part of the intention was to reduce the number of master files. My patch simply updates existing master files with new output. Are you saying that master files that are currently in DerbyNetClient could be removed because the master files in the top-level directory are identical? Perhaps that can be done as a separate patch, as I'm not sure exactly what Olav was looking at. My patch has gotten stale again and I suspect I need to run derbyall again. I'd like to get it in and then maybe we can look at that as a second phase. David Knut Anders Hatlen wrote: David Van Couvering <[EMAIL PROTECTED]> writes: Hi, Knut. Yes, it's true, this works, but I thought the whole point of rewriting the client so that client.am.SqlException doesn't extend java.sql.SQLException was so that we could directly use and throw the java.sql exceptions rather than our extensions of them. This is important in JDBC 4 when we have so many subclasses, and there is the expectation that JDBC 5 may very well have more to come. We could go back on this decision, but I don't see that it's worth it. What's wrong with printing out the actual exception class, which is the default behavior?I don't know why we would want to build our own "shadow" hierarchy of SQLExceptions just to achieve this. Note that even in the embedded code, the 40 factory creates vanilla java.sql exception classes and throws them. This fix is only for applications running with JDK 1.5 or earlier. I think the change I made, although a little white lie (the class is org.apache.derby.impl.jdbc.EmbedSQLException rather than java.sql.SQLException) is pretty reasonable, especially since it's only for older VMs, and will be unnecessary in some (distant) future when JDK 1.5 is no longer supported. Is there a reason you feel this isn't going to work? Thanks for the explanation, David. I think the change is reasonable. I don't have any strong opinion on what's the best message to print, but I thought I'd mention that there in fact was something we could do about it if you didn't think your solution was optimal. If we can avoid subclassing the standard java.sql exceptions, I agree that it is a good thing. I think Olav filed this issue in order to reduce the number of master files. Did you find any canons that could be removed after your change?
Re: [jira] Commented: (DERBY-1438) Text written by SQLException.toString differs between client and embedded driver
David Van Couvering <[EMAIL PROTECTED]> writes: > Hi, Knut. Yes, it's true, this works, but I thought the whole point > of rewriting the client so that client.am.SqlException doesn't extend > java.sql.SQLException was so that we could directly use and throw the > java.sql exceptions rather than our extensions of them. This is > important in JDBC 4 when we have so many subclasses, and there is the > expectation that JDBC 5 may very well have more to come. > > We could go back on this decision, but I don't see that it's worth > it. What's wrong with printing out the actual exception class, which > is the default behavior?I don't know why we would want to build > our own "shadow" hierarchy of SQLExceptions just to achieve this. > > Note that even in the embedded code, the 40 factory creates vanilla > java.sql exception classes and throws them. This fix is only for > applications running with JDK 1.5 or earlier. > > I think the change I made, although a little white lie (the class is > org.apache.derby.impl.jdbc.EmbedSQLException rather than > java.sql.SQLException) is pretty reasonable, especially since it's > only for older VMs, and will be unnecessary in some (distant) future > when JDK 1.5 is no longer supported. Is there a reason you feel this > isn't going to work? Thanks for the explanation, David. I think the change is reasonable. I don't have any strong opinion on what's the best message to print, but I thought I'd mention that there in fact was something we could do about it if you didn't think your solution was optimal. If we can avoid subclassing the standard java.sql exceptions, I agree that it is a good thing. I think Olav filed this issue in order to reduce the number of master files. Did you find any canons that could be removed after your change? -- Knut Anders
Re: [jira] Commented: (DERBY-1438) Text written by SQLException.toString differs between client and embedded driver
Hi, Knut. Yes, it's true, this works, but I thought the whole point of
rewriting the client so that client.am.SqlException doesn't extend
java.sql.SQLException was so that we could directly use and throw the
java.sql exceptions rather than our extensions of them. This is
important in JDBC 4 when we have so many subclasses, and there is the
expectation that JDBC 5 may very well have more to come.
We could go back on this decision, but I don't see that it's worth it.
What's wrong with printing out the actual exception class, which is the
default behavior?I don't know why we would want to build our own
"shadow" hierarchy of SQLExceptions just to achieve this.
Note that even in the embedded code, the 40 factory creates vanilla
java.sql exception classes and throws them. This fix is only for
applications running with JDK 1.5 or earlier.
I think the change I made, although a little white lie (the class is
org.apache.derby.impl.jdbc.EmbedSQLException rather than
java.sql.SQLException) is pretty reasonable, especially since it's only
for older VMs, and will be unnecessary in some (distant) future when JDK
1.5 is no longer supported. Is there a reason you feel this isn't going
to work?
David
Knut Anders Hatlen (JIRA) wrote:
[ http://issues.apache.org/jira/browse/DERBY-1438?page=comments#action_12422421 ]
Knut Anders Hatlen commented on DERBY-1438:
---
David wrote:
We can't override the toString() method on the network client, as
what's being returned to users is a vanilla java.sql.SQLException
(or one of its subclasses in JDBC4). So it's going to do the
default behavior and there's nothing we can do about it.
Actually, there is something we can do. The spec doesn't say that we
can't create subclasses of the provided exception classes, so we can
override the toString() method.
I tried this code
throw new SQLFeatureNotSupportedException("some error message") {
public String toString() {
return "SQLException: " + getMessage();
}
};
and it printed this message
SQLException: some error message
not
java.sql.SQLFeatureNotSupportedException: some error message
Text written by SQLException.toString differs between client and embedded driver
Key: DERBY-1438
URL: http://issues.apache.org/jira/browse/DERBY-1438
Project: Derby
Issue Type: Improvement
Components: JDBC, Newcomer
Affects Versions: 10.2.0.0
Environment: Sun JDK 1.5
Reporter: Olav Sandstaa
Assigned To: David Van Couvering
Priority: Trivial
Attachments: DERBY-1438-rev2.diff, DERBY-1438.diff
The first part of the string written by SQLExeption.toString() differs
between the Derby client driver and the embedded driver. The embedded
driver writes:
SQL Exception: Table/View 'DERBYDB' does not exist.
while the client driver writes:
java.sql.SQLException: Table/View 'DERBYDB' does not exist.
It would be good if we changed this so the same text is written by
both drivers. This reduces the difference seen when changing between
client and embedded Derby and it make it possible to reduce the amount
of sed-ing or the number of master file variants for some tests.
[jira] Commented: (DERBY-1438) Text written by SQLException.toString differs between client and embedded driver
[
http://issues.apache.org/jira/browse/DERBY-1438?page=comments#action_12422421 ]
Knut Anders Hatlen commented on DERBY-1438:
---
David wrote:
> We can't override the toString() method on the network client, as
> what's being returned to users is a vanilla java.sql.SQLException
> (or one of its subclasses in JDBC4). So it's going to do the
> default behavior and there's nothing we can do about it.
Actually, there is something we can do. The spec doesn't say that we
can't create subclasses of the provided exception classes, so we can
override the toString() method.
I tried this code
throw new SQLFeatureNotSupportedException("some error message") {
public String toString() {
return "SQLException: " + getMessage();
}
};
and it printed this message
SQLException: some error message
not
java.sql.SQLFeatureNotSupportedException: some error message
> Text written by SQLException.toString differs between client and embedded
> driver
>
>
> Key: DERBY-1438
> URL: http://issues.apache.org/jira/browse/DERBY-1438
> Project: Derby
> Issue Type: Improvement
> Components: JDBC, Newcomer
>Affects Versions: 10.2.0.0
> Environment: Sun JDK 1.5
>Reporter: Olav Sandstaa
> Assigned To: David Van Couvering
>Priority: Trivial
> Attachments: DERBY-1438-rev2.diff, DERBY-1438.diff
>
>
> The first part of the string written by SQLExeption.toString() differs
> between the Derby client driver and the embedded driver. The embedded
> driver writes:
>SQL Exception: Table/View 'DERBYDB' does not exist.
> while the client driver writes:
>java.sql.SQLException: Table/View 'DERBYDB' does not exist.
> It would be good if we changed this so the same text is written by
> both drivers. This reduces the difference seen when changing between
> client and embedded Derby and it make it possible to reduce the amount
> of sed-ing or the number of master file variants for some tests.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1438) Text written by SQLException.toString differs between client and embedded driver
[
http://issues.apache.org/jira/browse/DERBY-1438?page=comments#action_12417334 ]
Olav Sandstaa commented on DERBY-1438:
--
Personally, I prefer the text written by the embedded driver ("SQL Exception:")
over the text written by the client driver ("java.sql.Exception:"), but with
the introduction of the SQL exception hierarchy in Java SE 6 it might be better
to use the exact exception name (e.g.
"java.sql.IamSorryThisShouldNotHappenTodayException") which is what I think you
get if you call SQLException.toString() and running with jdk 1.6.
> Text written by SQLException.toString differs between client and embedded
> driver
>
>
> Key: DERBY-1438
> URL: http://issues.apache.org/jira/browse/DERBY-1438
> Project: Derby
> Type: Improvement
> Components: JDBC, Newcomer
> Versions: 10.2.0.0
> Environment: Sun JDK 1.5
> Reporter: Olav Sandstaa
> Assignee: David Van Couvering
> Priority: Trivial
>
> The first part of the string written by SQLExeption.toString() differs
> between the Derby client driver and the embedded driver. The embedded
> driver writes:
>SQL Exception: Table/View 'DERBYDB' does not exist.
> while the client driver writes:
>java.sql.SQLException: Table/View 'DERBYDB' does not exist.
> It would be good if we changed this so the same text is written by
> both drivers. This reduces the difference seen when changing between
> client and embedded Derby and it make it possible to reduce the amount
> of sed-ing or the number of master file variants for some tests.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1438) Text written by SQLException.toString differs between client and embedded driver
[ http://issues.apache.org/jira/browse/DERBY-1438?page=comments#action_12417330 ] David Van Couvering commented on DERBY-1438: I'll take a look at this and see what I can do. Thanks, Olav. > Text written by SQLException.toString differs between client and embedded > driver > > > Key: DERBY-1438 > URL: http://issues.apache.org/jira/browse/DERBY-1438 > Project: Derby > Type: Improvement > Components: JDBC, Newcomer > Versions: 10.2.0.0 > Environment: Sun JDK 1.5 > Reporter: Olav Sandstaa > Assignee: David Van Couvering > Priority: Trivial > > The first part of the string written by SQLExeption.toString() differs > between the Derby client driver and the embedded driver. The embedded > driver writes: >SQL Exception: Table/View 'DERBYDB' does not exist. > while the client driver writes: >java.sql.SQLException: Table/View 'DERBYDB' does not exist. > It would be good if we changed this so the same text is written by > both drivers. This reduces the difference seen when changing between > client and embedded Derby and it make it possible to reduce the amount > of sed-ing or the number of master file variants for some tests. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
