|
Let me Google that for you...[^]
I'm not questioning your powers of observation; I'm merely remarking upon the paradox of asking a masked man who he is. (V)
|
|
|
|
|
|
Check here[^]
The link to connectionstrings.com is in the article.
Although if you can, forget about access. There are free versions of MySQL, PostgreSQL, Oracle and SQL-Server which are far better.
hope this helps.
|
|
|
|
|
|
For you all, "if one method throws an exception, the other methods will not run." this is the main reason I am using separate try..catch blocks. So that, even if a function gives an exception, the next can execute.
Can you suggest me a nice approach other than I am using here to execute the next function even if an exception occurred during the first function.
My Code
public XmlDocument GetXML(string[] arrInputInfo)
{
string rtnErrno=null;
ArrayList rtnValidateLogin=null;
string rtnPostSMS = null;
string strStartDateTime = DateTime.Now.ToString();
string strEndDateTime = DateTime.Now.ToString();
DataSet dst=new DataSet();
string[] arrLogReq = new string[5];
string strLoginRef = "-999";
string strstatus = "20";
try
{
//Validate Input Details
rtnErrno = ValidateInputInfo(arrInputInfo);
if (rtnErrno != "0")
{
throw new Exception("Exception raised at Input Validation");
}
//Validate Login Details
rtnValidateLogin = objLogin.ValidateCPLogin(arrInputInfo[0], arrInputInfo[1]);
if (rtnValidateLogin[0].ToString() != "0")
{
rtnErrno = rtnValidateLogin[0].ToString();
throw new Exception("Exception raised at Login Validation");
}
else
{
dst = (DataSet)rtnValidateLogin[1];
strLoginRef = dst.Tables[0].Rows[0][0].ToString();
}
//Insert Message
rtnPostSMS = PostSMSText(arrInputInfo);
if (rtnPostSMS.ToString() != "0")
{
rtnErrno = rtnPostSMS[0].ToString();
throw new Exception("Exception raised at Inserting Message");
}
}
catch (Exception ex)
{
strstatus = "30";
LogErrorHelper.LogError(Constants.ERROR_WEBSERVICES_LOGFILE, ex, "BLL.CSMSService-->GetXML");
}
finally
{
GC.Collect();
}
try
{
strEndDateTime = DateTime.Now.ToString();
arrLogReq[0] = strLoginRef; //Login Ref no
arrLogReq[1] = string.Concat(arrInputInfo[2], "~", arrInputInfo[3]); //Mobile No and Message
arrLogReq[2] = strStartDateTime; //start time
arrLogReq[3] = strEndDateTime; //end time
arrLogReq[4] = strstatus;
//To Log Incoming Requests
rtnErrno = LogConfirmation(arrLogReq);
}
catch (Exception ex)
{
LogErrorHelper.LogError(Constants.ERROR_WEBSERVICES_LOGFILE, ex, "BLL.CSMSService-->GetXML");
}
finally
{
GC.Collect();
}
return GetFinalXml(rtnErrno);
}
|
|
|
|
|
..one does not add a try-block around each statement; not every statement throws exceptions, and it makes your code hard to read and harder to maintain.
DoSafe(() => { throw new Exception(); });
DoSafe(() => Console.WriteLine("hi"));
Console.ReadKey();
}
static void DoSafe(Action whatEva)
{
try
{
whatEva.Invoke();
}
catch (Exception)
{
}
}
Then again, if I ever come across code using above construct, I'll delete it without asking permission. And no, you don't need to call GC.Collect.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
Eddy Vluggen wrote: if I ever come across code using above construct, I'll delete it without asking permission
I really can't decide whether to vote you up for that comment, or down for introducing the concept of "On Error Resume Next" to c#... 
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952)
Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
|
|
|
|
|
I've been thinking about this a lot recently. So much code I see catches an exception, logs it, then just carries on.
I'm subscribing more and more to the idea (in general) that if something exceptional has happened, the application is now in an unstable state and should be shut down until investigation has found out what went wrong. Obviously exceptions which we sort of expect we can handle with try/catch blocks but for now anyway, I'm avoiding all exception handling for anything else except at the AppDomain level which logs it, emails an alert and Environment.Exits.
I hate exceptions. In fact, I've just removed TcpListener/TcpClient from my vocabulary because they are too prone to throwing them. The other end disconnected - is that really that exceptional? I'd argue not. TcpClient.Connect - couldn't connect, that's because I have started the other end yet. Why is there no TryConnect??
It's interesting in interviews that they always ask about Exceptions - try/catch/finally - what happens to disposable objects etc. What they should ask is not how you do it, but when and why you should do it and how you are going to recover afterwards.
Well, if you ask me, that is.
Regards,
Rob Philpott.
|
|
|
|
|
I'd agree - knowing when to catch is more important than how, and recovery / reporting is very important. But I'd rather log and report to the user than bomb to the OS - I remember too well how much I hated that with older apps and I'd lose all my data because I pressed the wrong key. At least if you report and stay alive you give the user the opportunity to "copy'n'paste" his typing into something else even if you can't save it directly any more.
And "log and ignore" is much, much better than "ignore"! 
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952)
Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
|
|
|
|
|
Yes quite! I omitted to say that my day-to-day development is server side Windows Services stuff, it would be a different matter on the client!
Regards,
Rob Philpott.
|
|
|
|
|
Rob Philpott wrote: So much code I see catches an exception, logs it, then just carries on.
Unless one can handle it, logging is all you can do. The idea would be that you look at the log (when dogfooding the app), and use it to stop logging the exceptions you DO expect, handle those you can, or provide a neat message to the user. You'll find that the amount of "unexpected" exceptions decline over time.
Rob Philpott wrote: I'm subscribing more and more to the idea (in general) that if something exceptional has happened, the application is now in an unstable state and should be shut down until investigation has found out what went wrong.
Halleluja! You're 100% right; tryordie is the way to go. If you don't, you'll encounter an equivalent of backing up data, swallowing the exception that your backup failed and continue to wreck the only valid datastore.
Rob Philpott wrote: Why is there no TryConnect??
Write one.
If you expect the exception, you can handle it.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Eddy Vluggen wrote: Write one.
Well I could, but I like to run the debugger with first chance exceptions being thrown, its a really powerful tool to track things that fail. Yes, I can ignore that particular exception but I'd rather not. The answers as it turns out is to use the socket class which isn't so fascist.
Regards,
Rob Philpott.
|
|
|
|
|
Add an attribute to that single method;
[DebuggerStepThrough]
static bool TryFail()
{
try
{
throw new NotImplementedException();
}
catch (NotImplementedException)
{
Debug.WriteLine("Caught expected NotImplementedException");
return false;
}
return true;
}
Rob Philpott wrote: Yes, I can ignore that particular exception but I'd rather not.
Did you mean "ignore each instance of that exception", or "that particular catch in that specific method"?
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
OriginalGriff wrote: I really can't decide whether to vote you up for that comment
An unhelpful remark is not worth the upvote.
OriginalGriff wrote: or down for introducing the concept of "On Error Resume Next" to c#...
Now that you mention it, there's an "abuse" button 
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Oh, that crossed my mind as well!
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952)
Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
|
|
|
|
|
We actually have a function that looks almost exactly like this in our code base. The difference is that it's called once for a user interaction, at the top level, and in the catch is some code that makes and displays an error UI.
'Log and carry on' is bad. 'Log, inform and don't crash the host application' is good 
|
|
|
|
|
Do not use exceptions to control flow of your code. Think of exceptions like "something bad happened and I don't know what to do NOW". The only valid reason to throw the exception is that current method is not able to recover from failure.
Failed validation of arguments is not a reason to throw the exception - just check the result and execute the rest of your code or not.
And yes, don't use GC.Collect() - forget the garbage collector exists and let it do its job.
--
"My software never has bugs. It just develops random features."
|
|
|
|
|
deflinek wrote: Failed validation of arguments is not a reason to throw the exception
Um. ArgumentException class[^]
"ArgumentException is thrown when a method is invoked and at least one of the passed arguments does not meet the parameter specification of the called method."
So yes, it is: if the argument must be between 0 and 100 and the actual argument is -42, then that's an ArgumentException candidate.
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952)
Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
|
|
|
|
|
I'm sorry, I wasn't clear enough You are absolutely right that if method expects certain format for arguments to do its job should throw an exception if they are not valid.
In my post I was refering to OP's code when he calls validation method, then check for result and throws exception for certain values but catches it later in the same method. and continue processing. This is pure evil in my opinion
My point was - throw an exception only if you can't handle the situation inside the method and only if it's... exceptional situation. Do not use exception to control the flow.
--
"My software never has bugs. It just develops random features."
|
|
|
|
|
I can agree with that - Exceptions are for problems, not an advanced form of return code... 
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952)
Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
|
|
|
|
|
Been there, done that 
As everyone else mentions do not use try blocks to catch exceptions in order to keep your application alive.
An exception is just that - something that is unexpected, so you need to rework your code so you actually deal with the conditions that lead to that exception.
While you have those try blocks in your code you won't know how many bugs your code has.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
Hi everyone,
I am using below codes to get information from HardDisk.
ManagementObjectSearcher HardwareQuerySearcher = null;
HardwareQuerySearcher = new ManagementObjectSearcher("SELECT * FROM Win32_DiskDrive");
foreach (ManagementObject hard in HardwareQuerySearcher.Get())
{
Hard hdd = new Hard();
hdd.Model = hard["Model"].ToString();
hdd.Type = hard["InterfaceType"].ToString();
hdd.Type = hard["SerialNumber"].ToString();
}
Do you know how to list/or show all fields/properties that existing in this query ?
For example: I am want to know wherether the field "SerialNumber" existing or not ?
Thanks and regards,
Tai
|
|
|
|
|
have a read of this Win32_DiskDrive class[^]
Every day, thousands of innocent plants are killed by vegetarians.
Help end the violence EAT BACON
|
|
|
|
|
|
MSDN[^] is your friend. 
Everyone dies - but not everyone lives
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
