Exception handling

  • Thread starter Thread starter Shelly
  • Start date Start date
S

Shelly

I want to tell the user if, for example, he has chosen a value of the
primary key for a new record already exists. What I do now is do a
try-catch with the sql insert. That prohibits page failure, but I want to
notify the user of the specific result -- other than a generic failure
message. I have searched and searched but I have found no place where there
is a list of the names of all the exceptions (for sql and others). Does
anyone know where it is? It MUST exist somewhere.

Also, is there an automatic way to feed this back to the user other than
having a label that has nothing in it and is populated by the error message?

Shelly
 
Shelly said:
I want to tell the user if, for example, he has chosen a value of the
primary key for a new record already exists. What I do now is do a
try-catch with the sql insert. That prohibits page failure, but I want to
notify the user of the specific result -- other than a generic failure
message. I have searched and searched but I have found no place where
there is a list of the names of all the exceptions (for sql and others).
Does anyone know where it is? It MUST exist somewhere.
Click to expand...

Why should there be a list? What if I add one tomorrow? What if Microsoft
adds one tomorrow?
 
I want to tell the user if, for example, he has chosen a value of the
primary key for a new record already exists. What I do now is do a
try-catch with the sql insert. That prohibits page failure, but I want to
notify the user of the specific result -- other than a generic failure
message. I have searched and searched but I have found no place where
there is a list of the names of all the exceptions (for sql and others).
Does anyone know where it is? It MUST exist somewhere.
Click to expand...

You're doing this backwards...

One of the first guidelines for exceptions is that you do everything you can
to stop them happening. In this case, you know that there's a strong
likelihood that the way you've written your web app means that it can
produce primary key violations. Therefore, eliminate that possibility and
you can (more or less) forget about it.

SELECT COUNT(*) FROM MyTable WHERE MyPrimaryKey = <value>

If that returns 1 rather than zero, don't even try to insert the record.
Also, is there an automatic way to feed this back to the user other than
having a label that has nothing in it and is populated by the error
message?
Click to expand...

pseudo-code follows:

if (CheckIfRecordExists())
{
ClientScript.RegisterStartupScript(GetType(), "recordExists",
"alert('Record already exists!'););
}
else
{
InsertRecord();
}
 
Mark Rae said:
You're doing this backwards...

One of the first guidelines for exceptions is that you do everything you
can to stop them happening. In this case, you know that there's a strong
likelihood that the way you've written your web app means that it can
produce primary key violations. Therefore, eliminate that possibility and
you can (more or less) forget about it.

SELECT COUNT(*) FROM MyTable WHERE MyPrimaryKey = <value>

If that returns 1 rather than zero, don't even try to insert the record.
Click to expand...

Of course that is the way to do it for this example. However, I only used
that as an example and there are other exceptions that should be trappable
(and not just in SQL). There should be a list somewhere.

In answer to the other responder (John Saunders), it is quite true that the
list is expandable. However, if YOU expand the list, then YOU know how it
was expanded. What I am taling about is the base list. Eons ago when I was
programming for VMS, we could add our own errors to a base list -- but there
WAS a base list published.
pseudo-code follows:

if (CheckIfRecordExists())
{
ClientScript.RegisterStartupScript(GetType(), "recordExists",
"alert('Record already exists!'););
}
else
{
InsertRecord();
}
Click to expand...

Thanks.

Shelly
 
It's a little trickier to handle Sql Server errors, but "exceptions should
be exceptional", and if you expect this behavior from time to time, then
you should handle it gracefully, rather than catching certain number
exceptions.
Click to expand...

Absolutely correct. If an exception is likely to occur, then it's not an
exception...
 
Of course that is the way to do it for this example.
Click to expand...

The same guideline applies to any other example - if an exception is likely
to happen, then it's not an exception...
 
Shelly said:
In answer to the other responder (John Saunders), it is quite true that
the list is expandable. However, if YOU expand the list, then YOU know
how it was expanded. What I am taling about is the base list. Eons ago
when I was programming for VMS, we could add our own errors to a base
list -- but there WAS a base list published.
Click to expand...

Wrong. This was a mistake in VMS, for the same reason. There was a list
published, but that list was subject to be changed at any time. In any
release at all, even in a patch release, new error codes could be added. At
any time at all, the text of the associated error message could be changed.
I used to joke that we should change the error text every release, just to
catch customers who were depending on the text of the error messages.

So, no, this is not the way to do it. If you'll give us a better idea of
what you're trying to accomplish, we may be able to help you. Especially
those of us whose experience spans KA10 to Pentium-n.
 
Back
Top