|
memory exception for about 90% of the time, come from memory leaks caused by not releasing objects.
There are a few occasions were you could anticipate and act accordingly.
Furthermore, I hope there is some testing involved before going into production, any memory issues will come up there and you can act accordingly without the necessary need of exceptions.
Mohammed Hameed wrote: my perception is not correct.
it is not about right or wrong 
|
|
|
|
|
These kind of exceptions still system can throw eventhough resources have been disposed/released.
This might happen if system's overall memory overflows.
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
|
|
|
|
|
V. wrote: IMHO one should go for defensive programming:
public double Divide(double term1, double term2){
double division = double.NaN;
if(term2 != 0){
division = term1/term2;
}
else{
division = double.Infinity;
}
return division;
}
instead of try/catch the DivideByZeroException.
If that's C#, you don't need any of that code. If you divide a double by 0, you won't get a DivideByZeroException; you'll get double.Infinity.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
that could very well be, didn´t test that.
|
|
|
|
|
I am catching the top level exception in a large chunk of my current application. I have two reasons for this, but I'm willing to listen to anyone who thinks this is "wrong" and learn a better development practice if I can:
1. I rely heavily on a third party webservice that is very fickle and unpredictable. I have exception handling in here when making calls to this so I can gracefully handle errors from this application for the user. However, even I as I typed this I realized I should be throwing specific exception and not general ones, so I'll be refactoring that code.
2. In general I prefer to capture exceptions and log them so when my users (these are internal applications) call and say they had a problem I can check the log file to help resolve the issue. WIth CustomErrors on the end user normally can't provide me with much in the way of useful information so I rely on my logs for production troubleshooting.
|
|
|
|
|
Very good question.
According to my view, you can catch specific exceptions for the methods, which you are sure what kind of exception(s) can occur. And for the other methods, which you are not probably sure of all possible exceptions, which may occur you can catch the top-level exception.
Obviously, in any case you need to log the exception details.
Note: I would recommend you to go through this entire discussion of this thread you will get more information and also check this link: http://msdn.microsoft.com/en-us/library/vstudio/ms229005(v=vs.100).aspx[^]
http://authenticcode.com
|
|
|
|
|
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 
|
|
|
|
|
johnsyd wrote: 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".
Presumably without any locking to ensure that concurrent changes don't get lost? 
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Enterprisey. It's like the modern version of emulating a 1-M relationship using a delimited string in a text column.
|
|
|
|
|
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 kind of already faced a similar problem with SOA architectures.
If you split your business logic across several self-contained services sooner or latter you'll end up needing to show, on a grid or a report, data that comes from several services.
You shouldn't, even if it's possible, do joins across services databases as it breaks all the decoupling principle but when performance starts to be an issue... you know how the story goes from now on don't you?! 
So the only reason I see here (even if it's not a good idea) is an attempt to implement this "SOA" concept but only at DB level (say... Service Oriented Databases?  ), separating "services" by database.
Now I'm curious to know if I'm right! 
|
|
|
|
|
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?
|
|
|
|
|
If the databases are all on the same server instance, there is little performance impact. However if on different server instances, there is a big impact.
It complicates issues like disaster recovery - say if one of the databases fails over but the others don't. You also have to keep all the database permissions in synch which can become quite onerous. If a stored procedure accesses tables on 5 different databases it needs to preserve permissions on all of them. You also need to make sure the database-level settings are consistent. Backups need to be coordinated, so if a restore becomes necessary, you're using backups taken at the same time.
My issue is when you have related tables and someone splits them into multiple databases ... I can't see any benefit in the splitting and there are ongoing maintenance problems you introduce by doing it. You also have multiple points of failure. You may want to keep tables which are often JOIN'ed on different physical disks for performance, but another member mentioned that you can do this within the same database using FILEGROUPs.
|
|
|
|
|
"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
|
|
|
|
|
Are they putting the databases on different physical drives? If so, they might not know about filegroups[^], which would allow them to put different tables from the same database on different drives.
Splitting related tables between different databases is a terrible idea. Apart from anything else, you can't have DRI between the tables. You end up using triggers - or worse, external application code - to enforce referential integrity.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
