You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Kristian Waagan (JIRA)" <ji...@apache.org> on 2009/01/08 10:28:59 UTC
[jira] Created: (DERBY-4005) Make DerbyIOException useful for error
messages requiring arguments to be constructed
Make DerbyIOException useful for error messages requiring arguments to be constructed
-------------------------------------------------------------------------------------
Key: DERBY-4005
URL: https://issues.apache.org/jira/browse/DERBY-4005
Project: Derby
Issue Type: Improvement
Components: Store
Affects Versions: 10.5.0.0
Reporter: Kristian Waagan
Priority: Minor
DerbyIOException is a subclass of IOException used to separate between "genuine" IOExceptions and exceptions generated by Derby in environments where only an IOException is allowed to be thrown.
Currently, the exception class carries an SQLState. If Derby catches DerbyIOException before IOException, it can generate a SQLException with the correct SQLState and throw it. The DerbyIOException must be attached to avoid loosing the original stack trace.
The problem arising with SQLExceptions requiring arguments for the message construction, is that the arguments are not available when the SQLException is constructed.
There are at least two solutions to this problem:
a) Save the arguments in the DerbyIOException
b) Save an SQLException in the DerbyIOException
The motivation for fixing this issue, is that the user sees different exceptions for the same root cause depending on which method is used to insert a string data value. In general the differences are between stream and non-stream methods, for instance PreparedStatement.setString and PreparedStatement.setCharacterStream.
For instance, the non-stream method will throw 22001 (data truncation), but the stream method will throw XJ001 (java exception).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-4005) Make DerbyIOException useful for
error messages requiring arguments to be constructed
Posted by "Kristian Waagan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12662369#action_12662369 ]
Kristian Waagan commented on DERBY-4005:
----------------------------------------
Note: Remember to change the master file for largedata/LobLimits.java if the error message for truncation failure is changed.
> Make DerbyIOException useful for error messages requiring arguments to be constructed
> -------------------------------------------------------------------------------------
>
> Key: DERBY-4005
> URL: https://issues.apache.org/jira/browse/DERBY-4005
> Project: Derby
> Issue Type: Improvement
> Components: Store
> Affects Versions: 10.5.0.0
> Reporter: Kristian Waagan
> Priority: Minor
> Attachments: derby-4005-option_b_preview.diff
>
>
> DerbyIOException is a subclass of IOException used to separate between "genuine" IOExceptions and exceptions generated by Derby in environments where only an IOException is allowed to be thrown.
> Currently, the exception class carries an SQLState. If Derby catches DerbyIOException before IOException, it can generate a SQLException with the correct SQLState and throw it. The DerbyIOException must be attached to avoid loosing the original stack trace.
> The problem arising with SQLExceptions requiring arguments for the message construction, is that the arguments are not available when the SQLException is constructed.
> There are at least two solutions to this problem:
> a) Save the arguments in the DerbyIOException
> b) Save an SQLException in the DerbyIOException
> The motivation for fixing this issue, is that the user sees different exceptions for the same root cause depending on which method is used to insert a string data value. In general the differences are between stream and non-stream methods, for instance PreparedStatement.setString and PreparedStatement.setCharacterStream.
> For instance, the non-stream method will throw 22001 (data truncation), but the stream method will throw XJ001 (java exception).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-4005) Make DerbyIOException useful for error
messages requiring arguments to be constructed
Posted by "Kristian Waagan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kristian Waagan updated DERBY-4005:
-----------------------------------
Attachment: derby-4005-option_b_preview.diff
Patch 'derby-4005-option_b_preview.diff' shows how option b can be implemented.
Thoughts:
o It pulls in o.a.d.impl.jdbc code in the o.a.d.iapi.types package.
o Is it right throw/generate SQLException at this level of the code, or should it be StandardException?
I read some of the comments from the Jiras created by Dibyendu Majumdar, and there is talk about removing StandardException. I have to agree that the organization of the error message code seems a bit off, and the contents of o.a.d.iapi.types don't seem to be optimal either.
Looking at where DerbyIOException is used today, I think we have the option of removing it as well. If we do that, the user will have to deal with IOException instead of SQLException for some error situations when inserting data with streams (length exactness check and truncation).
Comments are welcome.
> Make DerbyIOException useful for error messages requiring arguments to be constructed
> -------------------------------------------------------------------------------------
>
> Key: DERBY-4005
> URL: https://issues.apache.org/jira/browse/DERBY-4005
> Project: Derby
> Issue Type: Improvement
> Components: Store
> Affects Versions: 10.5.0.0
> Reporter: Kristian Waagan
> Priority: Minor
> Attachments: derby-4005-option_b_preview.diff
>
>
> DerbyIOException is a subclass of IOException used to separate between "genuine" IOExceptions and exceptions generated by Derby in environments where only an IOException is allowed to be thrown.
> Currently, the exception class carries an SQLState. If Derby catches DerbyIOException before IOException, it can generate a SQLException with the correct SQLState and throw it. The DerbyIOException must be attached to avoid loosing the original stack trace.
> The problem arising with SQLExceptions requiring arguments for the message construction, is that the arguments are not available when the SQLException is constructed.
> There are at least two solutions to this problem:
> a) Save the arguments in the DerbyIOException
> b) Save an SQLException in the DerbyIOException
> The motivation for fixing this issue, is that the user sees different exceptions for the same root cause depending on which method is used to insert a string data value. In general the differences are between stream and non-stream methods, for instance PreparedStatement.setString and PreparedStatement.setCharacterStream.
> For instance, the non-stream method will throw 22001 (data truncation), but the stream method will throw XJ001 (java exception).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.