We Keep Coding

C# selenium if statement

So I'm using an if statement and I would assume if that statement doesn't find/do what it's suppose to, then it should throw an exception right? Well for some reason I'm getting absolutely nothing, the if statement isn't working, yet I'm not getting an exception?
Example of code -
try
{
label1.Text = "Finding route";
string sxp = "//*[#id='s']";
if (driver.FindElements(By.XPath("sxp")).Count != 0)
{
driver.FindElement(By.XPath(sxp)).Click();
label1.Text = "sxp done";
}
}
catch
{
CheckRoute();
label1.Text = "Exception thrown";
}
and the response from my program is nothing as soon as it hits the " if " statement, because before that it changes label1 to specified string..

Since you are checking it with if statement it has nothing to do with Exception throw. Remove if and it will throw an exception when it cant find the element. Also access the message with e.Message() if I am not mistaking. In your case it should be ElementNotFoundException.
try
{
label1.Text = "Finding route";
string sxp = "//*[#id='s']";
driver.FindElement(By.XPath(sxp)).Click();
label1.Text = "sxp done";
}
catch(Exception e)
{
CheckRoute();
label1.Text = "Exception thrown";
}
catch(ElementNotFoundException e)
{
Console.WriteLine(e.Message());
}

I think you are confused about ifs and how they work. ifs don't throw exceptions if they don't evaluate to true. Exceptions are thrown in specific cases when something unexpected happens. On example would be if you used driver.FindElement() and the element wasn't found... that would throw an ElementNotFoundException.
In your case, you have done the right thing and used .FindElements() (plural) and because of this, your code will not throw an exception. So, because of this you can remove the try-catch and additional simplifications result in the code below.
label1.Text = "Finding route";
IReadOnlyCollection<IWebElement> routes = driver.FindElements(By.Id("s"));
if (routes.Count > 0)
{
routes.ElementAt(0).Click();
label1.Text = "sxp done";
}
else
{
CheckRoute();
label1.Text = "sxp not found";
}
I stored the resulting collection from the .FindElements() in a variable, routes, so that it can be reused. Your code was hitting the page twice. I removed the try-catch because it was not needed.

Handle Error for Task.Factory.StartNew

I am facing issue when i got exception in threading. My Code is as follows:
Task.Factory.StartNew(() => ComputeBackgroundAdjudicationTask(taskId, ComputeBackgroundAdjudication));
And ComputeBackgroundAdjudicationTask method is as follows:
private void ComputeBackgroundAdjudicationTask(long taskId, Action<int> completedAdjudicationJobHandler)
{
//My Logic
completedAdjudicationJobHandler(1);
}
Now what iam facing issue is in my logic suppose some exception is coming i want to log into some text file.
After i searched in net i found some answer is as follows.
Task.Factory.StartNew(() =>ComputeBackgroundAdjudicationTask(taskId, ComputeBackgroundAdjudication))
.ContinueWith(
task =>
{
if (task.Exception != null)
task.Exception.Handle(ex =>
{
System.IO.File.AppendAllText(#"C://test.txt", "Error:" + ex.Message + "\r\n");
return true;
});
}, TaskContinuationOptions.OnlyOnFaulted
);
Now its logging into text file. After logging into text file the thread is not starting again. Please help me to fix this.
Thanks in Advance.

In your example the exception terminates the task/thread and after that you log the cause of the thread termination.
It seems what you are searching for is more of this kind:
private void ComputeBackgroundAdjudicationTask(long taskId, Action<int> completedAdjudicationJobHandler)
{
while(true) {
try {
//My Logic
completedAdjudicationJobHandler(1);
}
catch(Exception ex) {
System.IO.File.AppendAllText(#"C://test.txt", "Error:" + ex.ToString() + "\r\n");
}
}
}
But this seems as if whatever completedAdjudicationJobHandler does is not really well designed.
I want to add: If whatever throws the exception will always throw the exception this leads to an infinite loop.
Edit 2016-01-07: Maybe I misunderstood the wanted effect again. As I understand the last comment you want to do things written at the position of // MyLogic and whether they fail or succeed want completedAdjudicationJobHandler(1); executed. In this case the code example would be:
private void ComputeBackgroundAdjudicationTask(long taskId, Action<int> completedAdjudicationJobHandler)
{
try {
//My Logic
}
catch(Exception ex) {
System.IO.File.AppendAllText(#"C://test.txt", "Error:" + ex.ToString() + "\r\n");
}
finally {
completedAdjudicationJobHandler(1);
}
}

Avoiding the PerformanceCounter.NextValue's InvalidOperationException exception

var counter = new PerformanceCounter{};
counter.CategoryName = "Process";
counter.CounterName = "% Processor Time";
counter.InstanceName = someProcessName;
if ( PerformanceCounterCategory.InstanceExists( someProcessName, "Process" ) )
{
// For any reason the process terminates EXACTLY at this point
counter.NextValue();
// we'll get a InvalidOperationException exception here
}
Is there any possibility to use PerformanceCounter.NextValue method in a safe manner. Just for the record, I know It's very unlikely to have this type of scenario.

Look at MSDN - InvalidOperationException is throwed when The instance is not correctly associated with a performance counter.
PerformanceCounter.NextValue Method
Try to initialize your counter with RawValue property:
// Initialize the counter.
counter.RawValue = Stopwatch.GetTimestamp();
If this won't help - check if category and counter names are valid

use try-catch like this:
var counter = new PerformanceCounter{};
counter.CategoryName = "Process";
counter.CounterName = "% Processor Time";
counter.InstanceName = someProcessName;
try
{
if ( PerformanceCounterCategory.InstanceExists( someProcessName, "Process" ) )
{
// For any reason the process terminates EXACTLY at this point
counter.NextValue();
}
}
catch(InvalidOperationException error)
{
//deal with exception
}

Catching exceptions correctly .net

I'm working in a new place and seeing a lot of things in the code I'm not comfortably with.
I've been seeing a lot of code like this:
try
{
dAmount = double.Parse(((TextBox)control.Items[someRow].FindControl("txtControl")).Text);
}
catch
{
dAmount = 0;
}
I read stackoverflow and the like frequently and I'm aware that is not right, but I'm debating myself about the best way to handle this.
The developer obviously thought setting dAmount=0; was a good way to handle the exception, but seeing how double.Parse can only throw 3 exceptions(ArgumentNullException, FormatException, OverflowException) and if we add the NullReferenceException in case the FindControl or other object comes back null, then it seems to me I get to cover all the cracks, however the code looks kind of ugly, and I'm looking for suggestions, a better approach maybe?
This is what I came out with
try
{
dAmount = double.Parse(((TextBox)control.Items[someRow].FindControl("txtControl")).Text);
}
catch ( NullReferenceException nullRefEx )
{
dAmount = 0;
nwd.LogError("***Message: " + nullRefEx.Message + " ***Source: " + nullRefEx.Source + " ***StackTrace: " + nullRefEx.StackTrace);
}
catch ( ArgumentNullException argNullEx )
{
dAmount = 0;
nwd.LogError("***Message: " + argNullEx.Message + " ***Source: " + argNullEx.Source + " ***StackTrace: " + argNullEx.StackTrace);
}
catch ( FormatException frmEx )
{
dAmount = 0;
nwd.LogError("***Message: " + frmEx.Message + " ***Source: " + frmEx.Source + " ***StackTrace: " + frmEx.StackTrace);
}
catch ( OverflowException ovrEx)
{
dAmount = 0;
nwd.LogError("***Message: " + ovrEx.Message + " ***Source: " + ovrEx.Source + " ***StackTrace: " + ovrEx.StackTrace);
}
BTW I don't control the logging function is from another team in here, I know is kind of ugly.
What about saving the exception in a general Exception and having only one nwd.LogError call at the end? any suggestions are welcome.

You're doing exactly the same thing with all of your exceptions, which rather defeats the purpose of catching them all separately. You should be catching different exceptions if you intend to actually do something different with each type.
Your finally block will run and zero out your value even if there are no exceptions.
You shouldn't be using exceptions for control flow in the first place; you should be writing the code so that no exceptions are thrown at all if the user inputs invalid data, rather than throwing and catching an exception for a non-exceptional use-case. In this context that's as simple as using double.TryParse.
Exceptions such as null reference/null argument exceptions, overflow exceptions, etc. should pretty much never be caught at all outside of a top level method that logs any fatal exceptions before failing gracefully. These are boneheaded exceptions; if you're getting them it's a sign that you have a bug in your code that you need to fix, not a problem that you should try to sweep under the rug and continue executing your program.

You should use Double.TryParse instead.
double number;
if (Double.TryParse(value, out number))
dAmount = number;
else
dAmount=0;
This is cleaner and avoids exceptions altogether.

Don't use finally because that will always set dAmount = 0, even if an exception isn't thrown. If you want to catch a general Exception, then a single catch (Exception ex) will suffice. If you want to catch those specifically, I would do the following:
try
{
// code here
...
}
catch (Exception ex)
{
if (ex is NullReferenceException || ex is ArgumentNullException
|| ex is FormatException || ex is OverflowException)
{
// handle ex
...
return;
}
throw;
}
In your case, your best option is to probably use Double.TryParse, like so:
double amount;
if(Double.TryParse(someValue, out amount)
{
// do something with amount...
}
else
{
// handle the error condition here
}

Catch a single exception that covers all those instances. The message in the log file should distinguish which type of exception was thrown.
string s = ....;
double d = 0;
try {
d = Double.Parse(s);
} catch (Exception ex) {
//Set default value
nwd.LogError("***Message: " + ex.Message + " ***Source: " + ex.Source + "***StackTrace: " + ex.StackTrace);
}
The key the other answers are missing is that he wants to log the exception... TryParse won't tell you why it didn't parse correctly, it just returns false and 0 in the out param.
The real question here is... is zero actually special? I.e. is 0 not a valid number for a person to put into the text box? How would the rest of the program tell whether the user entered a zero, or the zero was a result of the default value being returned on parse error?
The better plan, and one I use when I am getting a value object and might fail is to use a nullable...
string s = ....;
double? d = null;
try {
d = Double.Parse(s);
} catch (Exception e) {
nwd.LogError("***Message: " + ex.Message + " ***Source: " + ex.Source + "***StackTrace: " + ex.StackTrace);
}
return d;
Now the caller knows for a fact that an error occurred when you return null (versus some "magic value"). Using "magic values" unnecessarily complicates the semantics.
Even better is to simply let the error propagate (or re-throw it) to where it can actually be handled reasonably. What part of your code currently checks for that 0 "magic value" and does something different based on it? That's where your catch should be (or, catch and log and then rethrow).

Try/Catch isn't there to control flow of your methods. If you can't redesign whole thing then I'd do something like this.
public double Parse(...)
{
double value = 0;
string text = ((TextBox)control.Items[someRow].FindControl("txtControl")).Text;
double.TryParse(text, out value);
return value;
}

[C#]How to introduce retry logic into LINQ to SQL to deal with timeouts?

I need to find ways to add retry mechanism to my DB calls in case of timeouts, LINQ to SQL is used to call some sprocs in my code...
using (MyDataContext dc = new MyDataContext())
{
int result = -1; //denote failure
int count = 0;
while ((result < 0) && (count < MAX_RETRIES))
{
result = dc.myStoredProc1(...);
count++;
}
result = -1;
count = 0;
while ((result < 0) && (count < MAX_RETRIES))
{
result = dc.myStoredProc2(...);
count++;
}
...
...
}
Not sure if the code above is right or posed any complications.
It'll be nice to throw an exception after MAX_RETRIES has reached, but I dunno how and where to throw them appropriately :-)
Any helps appreciated.

If you get a timeout from your database, it's not very likely that it's going to respond in a timely fashion a few miliseconds later.
Retrying in a tight loop as you suggest is likely to make a bad situation worse because you would be placing an undue burden on the database server, as well as tying up a thread in the calling code. It would be safer to introduce a wait time between each retry.
For more advanced scenarios, you could consider a progressive wait pattern where you retry more frequently in the beginning and then with longer and longer intervals if you still get timeouts.
You may also want to look into the Circuit Breaker design pattern from the book Release It!, as well as many of the other patterns and anti-patterns described in that book.
The State pattern is a good fit for implementing Circuit Breaker.

Personally, I would use recursion here. It makes for cleaner code since the only "extra code" you have is a parameter into a function. For example:
private MyResult Foo(MyParameters mp, int repeatCall)
{
var result = null;
try
{
result = mp.dc.myStoredProc(...);
}
catch (MyException err)
{
if (repeatCall > 0)
{
result = Foo(mp, repeatCall - 1);
}
else
{
throw;
}
}
return result;
}
This is an ideal example for recursion, I think. Whatever is calling this need not be concerned with the looping and it makes MUCH cleaner code.

As Mark Seemann corrrectly mentioned, it's not a good idea to use a retry policy to deal with with timeouts. However, given a delay this might be a good idea after all. To implement it, you can use a custom action invoker that executes your action method and takes care of retries in case of an SQL exception. This way you don't have to take care of the retry policy in each and every action method's code.
We don't have database timeout in our system, but I am using the same technique to handle sql read deadlocks in a generic way.

We use something like this (prefer that a new EF Context is instantiated for each retry):
Sorry but the code for SqlExceptionUtil.IsSqlServerErrorType() could not be included (overly custom and many layers).
static public T ExecuteRetryable<T>(
Func<T> function,
out int actualAttempts,
string actionDescriptionForException = "SQL",
int maxTries = 3,
int pauseMaxMillis = 1000,
int pauseMinMillis = 0,
bool alsoPauseBeforeFirstAttempt = false,
bool allowRetryOnTimeout = false)
{
Exception mostRecentException = null;
for (int i = 0; i < maxTries; i++)
{
// Pause at the beginning of the loop rather than end to catch the case when many servers
// start due to inrush of requests (likely). Use a random factor to try and avoid deadlock
// in the first place.
//
if (i > 0 || alsoPauseBeforeFirstAttempt)
Thread.Sleep(new Random
(
// Default Initializer was just based on time, help the random to differ when called at same instant in different threads.
(Int32)((DateTime.Now.Ticks + Thread.CurrentThread.GetHashCode() + Thread.CurrentThread.ManagedThreadId) % Int32.MaxValue)
)
.Next(pauseMinMillis, pauseMaxMillis));
actualAttempts = i + 1;
try
{
T returnValue = function();
return returnValue;
}
catch (Exception ex)
{
// The exception hierarchy may not be consistent so search all inner exceptions.
// Currently it is DbUpdateException -> UpdateException -> SqlException
//
if (!SqlExceptionUtil.IsSqlServerErrorType(ex, SqlServerErrorType.Deadlock) &&
(!allowRetryOnTimeout || !SqlExceptionUtil.IsSqlServerErrorType(ex, SqlServerErrorType.Timeout)))
throw;
mostRecentException = ex;
}
}
throw new Exception(
"Unable to perform action '" + actionDescriptionForException + "' after " + maxTries +
" tries with pauses of [" + pauseMinMillis + "," + pauseMaxMillis + "]ms due to multiple exceptions.",
mostRecentException);
}
Usage:
List<SomeTableEntity> result = DatabaseHelpers.ExecuteRetryable<List<SomeTableEntity>>(() =>
{
using (EfCtx ctx = new EfCtx())
{
return ctx.SomeTable.Where(...).ToList()
}
}, out int actualAttempts, allowRetryOnTimeout: true);
It would be nice if someone would show how to disguise the wrapping code behind a custom Linq construct like: WithRetry(...).