My work with SQL States in Derby seems to indicate in general that you
create a new SQL State with the same class for each new message. If
there are two errors that map to exactly the same SQL State, I think
there is a way to do this too, but it doesn't seem to be the norm.
David
Kristian Waagan wrote:
Hello,
In my work on DERBY-746 I have encountered a new type of error that has
no particulary suitable existing SQLState or error message. This is my
first bug fix, and I was wondering what the general policy for adding
new SQLStates is.
Am I free to add whatever I see fit?
In this particular case, I have three choices:
1) Use an existing, but very general state/msg.
2) Create one new state/msg for two different, but related, errors.
(can add an argument to the error message)
3) Create two new states/msgs.
Is it a goal to keep the number of states and messages down, or doesn't
it matter? From a user perspective, I think a more precise message would
be best (e.g. instead of getting "invalid key" you get something like
"key has invalid length" and "key contains invalid characters").
Feedback on this is appreciated!
--
Kristian
begin:vcard
fn:David W Van Couvering
n:Van Couvering;David W
org:Sun Microsystems, Inc.;Database Technology Group
email;internet:[EMAIL PROTECTED]
title:Senior Staff Software Engineer
tel;work:510-550-6819
tel;cell:510-684-7281
x-mozilla-html:TRUE
version:2.1
end:vcard
