 |
|
Let me start this discussion something like this:
Obviously, we need to catch only specific exceptions and that too if it is required.
But unfortunately this is not the case in my company. Here for each and every method (regardless it is required or not) you will find a single catch catching only the top Exception. Error logging is being done here and then sometimes it is being rethrown.
I dont understand this scheme/practice and hence I discussed regarding it with my Developers, peers, and Manager(s) but most of them say something like these:
--> 'It does not make any difference'
--> 'We are doing in this same fashion everywhere from beginning'
--> 'My TL asked me to follow like this'
--> 'It is a client's requirement to log all top exceptions all times and it should not be missed anytime'
Is any point from above is applicable?
Let's have some discussion please so that I get a broad and clear picture.
Thanks.
Understand SOLID! Believe SOLID! Try SOLID! Do implement live SOLID; your Code base becomes Rock SOLID!!!
http://www.codeproject.com/Articles/593751/Code-Review-Checklist-and-Guidelines-for-Csharp-De
|
|
|
|
|
Doesn't that go against the whole point of exception handling? try/catch is not equivalent of VB's On Error Goto.
Also if the code breaks all the time then its hardly an 'exception' is it?
And debugging must be a pain, as VS will break in catch block, not where the error occurred wont it?
How many of these catch blocks are entered on regular operation? Exceptions aren't cheap to throw after all.
Also is a try/catch block 'free' of any performance/memory penalty?
|
|
|
|
|
You raised very valid points. Thanks.
Understand SOLID! Believe SOLID! Try SOLID! Do implement live SOLID; your Code base becomes Rock SOLID!!!
http://www.codeproject.com/Articles/593751/Code-Review-Checklist-and-Guidelines-for-Csharp-De
|
|
|
|
|
|
That's a nice explanation Jarek!!! Thanks.
So you mean you support placing try/catch blocks everywhere and catching the main Exception everywhere, right? (But I'm still not supporting this practice)  .
As you said, if it is properly written then no exceptions at all. But yes this is not the case always for some exceptions like MemoryOverflow, AccessDenied, etc. Therefore for only these kind of exceptions might specifically catch them.
Understand SOLID! Believe SOLID! Try SOLID! Do implement live SOLID; your Code base becomes Rock SOLID!!!
http://www.codeproject.com/Articles/593751/Code-Review-Checklist-and-Guidelines-for-Csharp-De
|
|
|
|
|
Just remembered another stunning design stumble in the same area as the multiple database scenario ... they had a SQL table and decided that because the majority of requests required the output in XML format, it would be "best practice" (that weasel word again) to convert the entire table into a blob of XML. They then dropped the original table and recreated it as a table with 1 row and 1 column, into which they inserted the XML blob.
Unfortunately they had not realised that most requests wanted a subset of the table, not the entire table. So for each request, the XML blob had to be converted to a temp table, the appropriate SELECT run on it, and the results sent back to the requester as XML ... Phew!! Inserts, updates and deletes had to go through the same process: XML blob -> temp table -> apply insert/update/delete -> convert back to XML blob, save back in the "table".
|
|
|
|
|
Precious...
Are you still working there?
Careful, it might be contagious... 
|
|
|
|
|
Haha, I'm too lazy a programmer to make work for myself like that 
I'm on contract :(
|
|
|
|
|
|
Yeah, that basically sums it up 
|
|
|
|
|
I work for a large company which has an odd habit of splitting off logically related tables into separate databases. So instead of one database ABC, you have databases ABC_CLIENT, ABC_PORTFOLIO, ABC_PRICING, etc. To join client data to their own portfolio data, you need to go cross database and to include pricing data means yet another cross database connection.
A friend who works for another large company in the same industry says that his company thinks this is "best practice". No one I've talked to thinks this is a good idea, let alone "best practice". What do you think?
|
|
|
|
|
Client and pricing information in separate databases. 
Wait until the company grows and amount of transactions get to several millions per day.
|
|
|
|
|
Exactly -- they get away with it because this particular product has limited number of clients and transaction volumes.
|
|
|
|
|
|
Our company (banking industry, over 500'000 credit cards (at the time I worked in that area, so now it could be doubled), bank accounts, ecc. Split between credit card, bank and hybrid (for both), but that's it so far in DB2 area. There are some ORACLE DBs used mainly internaly and some MS SQL DBs used for internal intranet web sites, but that's OK because totally unrelated.
The signature is in building process.. Please wait...
|
|
|
|
|
|
I think you are right but hope you are wrong The key to SOA is to implement throughout the vertical, if all is not in SOA becomes an inhibitor and a PAIN.
____________________________________________________________
Be brave little warrior, be VERY brave
|
|
|
|
|
I would put them in the same DB, but in different schemas.
|
|
|
|
|
Yep, MS's sample AdventureWorks does exactly this.
I don't understand the reasons, but on SQL Server how much penalty is there to having multiple databases?
|
|
|
|
|
"Best practice" or "Common pattern", people tend to confuse the 2... Best practice will have justification(s), common pattern probably won't. Best practice is best for specific reasons / conditions, and those will tell you if it applies to you. Try to get the detail of the best practice and you are likely to find out that it is more common pattern.
Something like this sounds more like common pattern than best practice, but I still don't see the advantage / point of doing it.
IT people (including me) tend to over complicate things, this sounds like one of those.
____________________________________________________________
Be brave little warrior, be VERY brave
|
|
|
|
|
I'm re-writing a legacy ASP application. There's an expensive call to an external webservice and a database to determine a calculated setting specific to the person logged in.
On the first page this calculation is done and the result is stored in a session variable.
On every subsequent page the session variable is ignore, the value is recalculated and then stored in the session variable again!
Some days I don't know if to laugh or cry.
|
|
|
|
|
Sometimes, you just want to go into a code review with a baseball bat and a spiked glove... 
The universe is composed of electrons, neutrons, protons and......morons. (ThePhantomUpvoter)
|
|
|
|
|
Cool, who ever wrote the code invented the write-only variable.. What shall we call it? "Wrariable"?
|
|
|
|
|
That kind of innovation must be why this guy is now a manager. My only solace in that is that he's no longer writing "code".
|
|
|
|
|
He's a manager now? Well, that explains a lot. I know quite some managers who also write (or wrote) code, and that was among the most horrible code I've ever seen. Think you still might find examples here in TWATW.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Rant 
Admin 
Submit an article or tip
Post your Blog
), separating "services" by database.
