|
Eddy Vluggen wrote: than having a lot of exceptions (and invalid states) that I don't know of.
Been writing servers for 15 years, high capacity ones for 10, and I have never seen that.
What I have seen are a lot of null pointer exceptions caused by programming adaptors in plugin architectures doing dynamic processing. Which means that the ALL transactions in flight would then fail simply because a one time data set caused a bug to show up.
And I can note that in most cases the adapter code was not written by me but the plugin architecture was.
I have seen catastrophic failures but they take the server down. And in that case catching the exceptions at least for the purpose of logging is critical.
Eddy Vluggen wrote: I'd rather have them complain once and explain that it's a bug
I rather not have to explain anything when all the customers suffered some sort of failure due to something that could have been avoided.
|
|
|
|
|
Down vote countered - not checking or catching errors is just lazy programming, and is unfair on the people who pay our wages! 
This message is manufactured from fully recyclable noughts and ones. To recycle this message, please separate into two tidy piles, and take them to your nearest local recycling centre.
Please note that in some areas noughts are always replaced with zeros by law, and many facilities cannot recycle zeroes - in this case, please bury them in your back garden and water frequently.
|
|
|
|
|
OriginalGriff wrote: Down vote countered
Thanks.
|
|
|
|
|
OriginalGriff wrote: not checking or catching errors is just lazy programming
No-one advocates "not" checking them; so the statement that one should is superfluous.
Using a pokemon-handler is lazy; if you expect an exception, than you can see if you can handle it locally. Unhandled exceptions would be logged in a single place.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
Eddy Vluggen wrote: No-one advocates "not" checking them;
Um.
Eddy Vluggen wrote: And yes, I'd rather see my app die, than pretend nothing happened (and have it continue with corrupted data that gets saved later)
Eddy Vluggen wrote: I'd rather have them complain once and explain that it's a bug that will never resurface, than having a lot of exceptions (and invalid states) that I don't know of.
I love the PHP-approach; either do or die, don't fake it.
This message is manufactured from fully recyclable noughts and ones. To recycle this message, please separate into two tidy piles, and take them to your nearest local recycling centre.
Please note that in some areas noughts are always replaced with zeros by law, and many facilities cannot recycle zeroes - in this case, please bury them in your back garden and water frequently.
|
|
|
|
|
OriginalGriff wrote: And yes, I'd rather see my app die, than pretend nothing happened (and have it continue with corrupted data that gets saved later)
I do not advocate there that one should not handle exceptions. "Do or die" means that I'll try to close the app as gracefully as possible, with an apoligy to the user that an exception occured.
OriginalGriff wrote: I'd rather have them complain once and explain that it's a bug that will never resurface
Does still not mean that I do not have a global exception handler; it's implemented, but it does not "hide" exceptions and pretend all is well. It get's logged, and once investigated, one can easily push an update that ignores that specific exception if that's safe.
Imagine medical software being like that, and using the "default gender" if that information is lost after an exception on a conversion.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Eddy Vluggen wrote: Imagine medical software being like that, and using the "default gender" if that
information is lost after an exception on a conversion.
Ridiculous analogy.
Computers are deterministic even if it seems random at times. Catastrophic system failures in code that has even a reasonable amount of quality control are rare. Even rarer to happen in production. What happens much more are unexpected but normal errors. And at least in 24x7 servers (which you don't seem to be describing) it can't just quit because of an little known and non-tested data path results in a null pointer exception.
When catastrophic errors do occur they are, oddly enough, catastrophic. They cause the entire system to fail and it is obvious.
So you are hypothesizing some extremely rare circumstances where such an error allows the system to keep running yet corrupts the entire system completely such that there are no other validation checks that would catch anything (my code has validation checks.) And that just is not reasonable when compared to unexpected conditions which can be ignored and which occur much more often.
|
|
|
|
|
Normally I don't us try-catch block. Except for exceptions I code myself and if there's something really not sure.
|
|
|
|
|
Try to avoid try-catch when you can. Often an if/else statement can help you out. (divide by zero, file exists, eof, ...)
That doesn't mean you shouldn't use try/catch, but use them were appropriate. IOW some 'exceptional' thing might happen. (an object has a null value although it shouldn't, ... )
Hope this helps.
|
|
|
|
|
Dear,
Please help me to get C# code to Get User Privileges in a machine for a specific user.
I will have a Service userName like
String userName = "myDomain\userName";
String remotemachineName = "RemoteMachineName";
Form my C# code, I should be able to find the User Priviliges for the User in the specified Machine.
GetUserPrivileges(userName, remotemachineName)
Thanks for the help in advance.
Regards,
Rijz
|
|
|
|
|
|
I just ran into a real headscratcher. I have code that does the following:
var textReader = new StreamReader(path + "\\web.config");
var fileContents = textReader.ReadToEnd();
if (fileContents.IndexOf(oldPwd, StringComparison.Ordinal) == -1)
{
Log("Old Password Not Found.", 0);
}
else
{
Log("Replacing old password", 1);
fileContents = fileContents.Replace(oldPwd, newPwd);
}
What I've found is that if the oldPwd contains ^ then things get weird.
1. If the old password ends in a ^, e.g. 123^ then the IndexOf works, but the Replace does will keep the ^ intact. So, with oldPwd = 123^ and newPwd = 456 then Replace will leave the file looking like 456^
2. If the old password has a ^ in the middle of it then IndexOf will return a -1.
I'm baffled to be honest and not sure if it has to do with how I'm reading the file in or what. But I tried this on an online compiler and it worked just fine. So it has to be me, right?
EDIT: I also tried it in my code with hard coded strings and it behaves just fine:
var mystring = "this is a password 123^ yeah";
Console.WriteLine("Did it find it: " + mystring.IndexOf("123^", StringComparison.Ordinal).ToString());
Console.WriteLine("Did it replace it: " + mystring.Replace("123^", "456"));
mystring = "this is a password 123^456 yeah";
Console.WriteLine("Did it find it: " + mystring.IndexOf("123^456", StringComparison.Ordinal).ToString());
Console.WriteLine("Did it replace it: " + mystring.Replace("123^456", "abcdefg"));
FURTHER EDIT: Apparently if I run this through Visual Studio and step through the code it works fine. When I compile the code and run it from the command prompt it exhibits the behavior I outlined above.
modified 22-Aug-13 11:35am.
|
|
|
|
|
The web.config file is just an xml file, so perhaps the way to deal with this is to load the file as an XMLDocument and then simply navigate to the node containing the old password and change its value.
I wasn't, now I am, then I won't be anymore.
|
|
|
|
|
Unfortunately I don't always know which node the password will be in which is why I went with treating it as a string.
|
|
|
|
|
This confused me a while back as well. ^ is the escape character on the command line, so escape it (^^) and it should work as expected.
|
|
|
|
|
I owe you a beer! Thank you!
|
|
|
|
|
I'm using dataset for get values the table on access. The field date_ is shown in listview on format mm/dd/yyyy, but i need format dd/mm/yyyy.
I load values in listview with the code:
listview_.DataContext = _dataSet;
I tried:
string strDate = _dataset.Table["table"].Rows[0]["field_date"].ToString();
_dateset.Tables["table"].Rows[0]["field_date"] = DateTime.ParseExact(strDate, "dd/MM/yyyy", CultureInfo.CurrentCulture);
But not work. What can i do ?
|
|
|
|
|
|
I'm using WPF, the listview not contains listview.subitem.
|
|
|
|
|
As per this answer: Source
<quote>
Simple change the StringFormat in your binding.
DisplayMemberBinding="{Binding Path=field_date, StringFormat='dd/MM/yyyy'}"
I wasn't, now I am, then I won't be anymore.
|
|
|
|
|
Very very tnks Marcus Kramer. Its work
|
|
|
|
|
I want to add.. DateTime.TryParse(x) is a good method to see if the date is even going to parse first.. also... it does not account for null data.. so you may need to add a little logic there to handle null.
=)
|
|
|
|
|
tnks forbiddenx 
|
|
|
|
|
I'm about halfway through an e-book, hopefully I'll retain enough information to pass the certification test…
I want to quit reading for now and just get my hands dirty in some coding… The examples and exercises are fairly simple and there more for reinforcing what the book was trying to teach…
I thought I would try my hand at creating/coding my own "RSS reader"… That should be fairly simple, shouldn't it?
A web scraper of some sorts should only take about 15 lines of code or less, then parsing that information might even be less than 10 lines of code…
What are the major differences between Windows forms and WPF?
Why choose one over the other?
I just want to create a simple functioning program, it doesn't have to look pretty or anything…
It doesn't have to automatically update or listen to the RSS feed for when it makes changes, that's a feature I can add in later on down the line.
Any kind of feedback towards design practices/patterns would be appreciated.
Thanks for taking the time to read this,
Rob
|
|
|
|
|
I think a web scraper most likely would take substantially more than 15 lines of code.
In my opinion, the biggest difference between WinForms and WPF is that WinForms is easy, and WPF has a steep learning curve.
If you're new to programming, I would start with WinForms.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
