[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
Re: login stored procedure
Exception is something that causes normal code flow interruption and must be handled. If it isn't - then it would cause the exception on any attempt to do anything like accessing non-public data. So, I prefer handling all the exceptions instead of using return codes.
Performance issues aren't important here, unless the primary occupation of the project is the failed logins. I've tried to measure exception speed for some very strange purpose several years ago, and even back then it was around ~1000/sec.
2008/12/19 Ilya A. Volynets-Evenbakh
<ilya@total-knowledge.com>
No, not quite true. The way you had your original engine.xml
configured, it was very easy to create load which would exhaust
available database connections and result in login failure, which
wasn't. Also, if cppserv is started with wrong database credentials,
or postgresql goes down, it all results in exceptions during login,
which aren't login error. Not giving that info to end user (and admin)
is not going to help anyone.
Another important point: While I don't know how exceptions
affect stored procedure efficiency, they certainly affect C++ code
badly. IOW, if we don't have to throw an exception, it's better
if we don't.
Ilya.
Alexey Parshin wrote:
Frankly speaking, a login error is an exception, no matter what causes it - bad username/pass or db problem.
In reality, 99% of the exceptions here would be invalid password.
2008/12/19 Ilya A. Volynets-Evenbakh <ilya@total-knowledge.com <mailto:ilya@total-knowledge.com>>
It would be nice to change login stored procedure
in a way that would let it indicate login failure
via return value. This would allow to differentiate
between login failure and database error conditions
in UuServlet code. As of now, failure to connect to
database is treated as login failure, which isn't
right.
As a workaround, I'm now checking for the error string
in exception, but that feels ugly.
Ilya.
--
Alexey Parshin,
http://www.sptk.net
--
Alexey Parshin,
http://www.sptk.net