|
OriginalGriff wrote: Nothing, but nothing, is so damn annoying as losing an hour's work because a programmer didn't bother to allow for an alpha character in a numeric field!
Yes, it's loosing a day because that exception is swallowed somewhere deeply within the system.
OriginalGriff wrote: Have you never sworn because an app went "...caused an exception and needs to close" and you lose a bunch of work?
There's an auto-save, but my Ctrl-S reflex is still alive.
And yes, I'd rather see my app die, than pretend nothing happened (and have it continue with corrupted data that gets saved later)
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
I'm not saying "swallow it" and "pretend nothing happened".
I'm saying use the tools and locate it while you (as a programmer) can still prevent it adversely affecting the user. Then report it, log it (both is good) and give them a chance to do something. Just letting your program crash is just being lazy! 
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: Just letting your program crash is just being lazy!
Aight.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
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.
=)
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
