Is there any truth to the explanation given by our software vendor? I asked for better error handling and this is their response. I feel the response is somewhat dishonest to say catch and re-throw is not unhandled exception, so I'm hoping to get a second opinion from y'all programmers here. (I'm not a programmers, so I may be totally wrong.)
"Please note that an error message shown by the application actually is not unhandled exception. In case when a critical error happens (and losing SQL server connection is such a case) we catch a then re-throw exception in a way that allows to display exception content and force the user to close the application. I understand that it looks not very user friendly and we will try in the future to come up with a better solution but for now the message is clear and allows easy troubleshooting since when connection is lost we are not able to insert the exception into the application log."
What they are saying makes sense. If the application has lost connection to the database server then there isn't a connection to reattempt the connection over.
However at what point it should simply give up and how it presents that to the user are what can be debated. Much better the user sees a graceful failure, clicks ok and logs a help-desk ticket than suffers a mild heart attack when presented the raw error message. I also hate it when application errors present connection strings. You might have good reason to keep that hidden - especially from that shit, Bob in finance, who will then spend the rest of the week trying to directly connect Excel to the database...
Basically a lot of SQL Server databases are hosted on clusters - either of the failover kind on shared storage or of the database replica kind. In either case it is common for .Net developers to write logic into their code to gracefully deal with the chance that a database has failed over to a different server, or just isn't there at all. When it does that all connections will fail until recovery is complete usually somewhere between 10 - 45 seconds depending on a few factors. Ultimately if there is a serious error the user should be presented with a graceful error message that tells them to go do something else, log a call or try later etc. Any company selling SQL Server hosted database solutions as part of their application ought to grasp this...
You might find this page helpful:
Thinking about this a little more, and just to clarify my earlier answer the developers really should use a try/catch on the connection attempt. If it fails it presents the user with a graceful error message. I guess that is the answer you were looking for :-)
P.S. I am not a developer though, a grown up might be along in a while...
Yeah, this isn't cool for commercial software. It would possibly be forgiveable if this was an edge case exception, out of nowhere. But a SQL connection error isn't out of the ordinary. Visual Studio should have indicated to them that the call they are making could throw a connection/endpoint error. Indicates they just throw that all the way out to the OS. Like @BGL indicated, they should be handling connections, usually with a retry and/or an error pop-up.
"...not unhandled..." -> "...re-throw...".
It's unhandled, that's bullshit. If an exception is caught and then no handling of the problem occurs and it is simply rethrown all the way to JIT, then it's unhandled. This is a minor technicality and evasive. They are likely making excuses for whatever mess they ended up in that makes simply re-establishing the connection impossible.
Having worked a lot with inherited code, I've been in such a situation before in which a system is so poorly designed that you can't handle an exception appropriately. The difference is, I was honest about this problem.
Seems alot like a continue at your own discord thrown exception, not really that fishy.
If it was truly Unhandled it would just have shown you a pretty window saying blabla error, blabla i shut down.
What they're saying is "Hey i met a error, should i try and recover/reconnect, or just shut down?", this could be a lost connection, your harddrive blew up, or a nuke hit your ISP, either way something went avry, and they're just asking do you wanna retry, or just quit.
Albeit programmer language can be stupid at times(Most of the time actually).
I'm guessing if you said continue, it would just retry and throw the same exception, which would go on, and on, and on.....
until the error either fixed itself or you clicked quit.
Yeah just to mirror some of the responses, it seems the program got an unrecoverable error. It could have been caught and re-thrown, but it doesn't change the fact it is not handled. So they haven't programmed in a case or process for handling bad connections, prompting the user to retry, fix the settings, or what ever.
I hope they spend the time not doing that, on making the rest of their code better :)
Looks like clicking on 'continue' won't help, as it often doesn't. JIT is a debugging tool, not a catch-all exception handler for lazy developers. Using JIT for crash reports is fine, but calling it an exception handler is misleading at best.
Thanks for all the responses. This is an enterprise software running on a RDS server, so all the users got this message at the same time and we needed the admin to restart the application. Clicking on 'continue' closes the program as well, so I guess that is their contribution to the error-handling process.
I think it was really off-putting to me that they are using a technicality in response to my request of improving error handling and then tried to fish for compliments by saying how clear the error message was. :\
By the way, I apologize on behalf of Bobs from finance everywhere... lol :)