[
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.
