Quote:
Originally Posted by Katsunami
In that case, the degrees and the universities awarding them are useless. Yes, I knew a lot of coding and best practices before I began studying, but I did learn a lot of things that I would never have learned on my own, except when doing it wrong and finding out about it the hard way.
On exceptions: I never understood those. I still don't. Try-Catch? WTF. So you just TRY if something works, and if it doesn't, you throw an error. That feels like trial and error. Maybe I'm old school, but I rarely use exceptions.
If there is one thing I try to adhere to, then it is that my code must never crash and always return either a usable result, or an error. Using an exception (with which your function exits unexpectedly) instead of an error code (with which your function terminates normally) is IMHO no better than a controlled crash.
edit: Funnily enough, Joel Spolsky agrees with me, again. (This guy is a well-respected software developer; to such an extent in fact, that I consider myself to be either right if my opinion corresponds with his, and wrong if it doesn't.) |
Exception handling (Try/Catch) came out of academia. Basically, a bunch on non-practicing programmers decided that returning errors was wrong, and decided to force us to use, as you so aptly termed it, a controlled crash. And, of course, unless you have try/catch blocks around every statement, you're never quite sure what triggered the exception.
Joel is a practising programmer, so he knows how stupid the whole try/catch thing is.
The really stupid thing is that Microsoft is moving the error handing in SQL Server into a try/catch model; check out the reduced functionality of THROW as opposed the RAISERROR. I'm sorry, but does Microsoft think we are too stupid to set our own Severity (which is probably mostly used to force the PRINT and RAISERROR messages to flush to the SSMS (or is it SSMC?) session.