Site down watir-webdriver

Ruby
1

Whenever a site is down it keeps on looking for it for sometime and
throws error:
the instruction I run is:

browser.goto(site_url)

C:/Ruby187/lib/ruby/1.8/timeout.rb:64:in rbuf_fill': execution expired (Timeout::Error) from ../lib/hands.rb:74:injoin’
from …/lib/hands.rb:74
from …/lib/hands.rb:72:in `each’
from …/lib/hands.rb:72

How to catch this error?

2

you want

begin
browser.goto(site_url)
rescue Timeout::Error
#do something
end

3

Joel P. wrote in post #1083434:

you want

begin
browser.goto(site_url)
rescue Timeout::Error
#do something
end

I did it like:

begin
browser.goto(site_url)
rescue Timeout::Error=>e
#do something
end
but its not catching exception and giving the error what I mentioned.

What kind of error is :

C:/Ruby187/lib/ruby/1.8/timeout.rb:64:in `rbuf_fill’: execution expired

4

Are you sure this is the browser timing out and not the thread? I’ve
never used threads before…
It might be possible to trap the error within your browser.goto and hand
it back to the join statement without that error?

5

Joel P. wrote in post #1083434:

you want

begin
browser.goto(site_url)
rescue Timeout::Error
#do something
end

at line 74 I have the fowllowing code:

child_thread.each do |t|
#wait for child thread.
if t!=nil
t.join #line: 74
end
end

6

Which line is causing the error;

browser.goto(site_url)

or

t.join

?

7

Joel P. wrote in post #1083529:

Are you sure this is the browser timing out and not the thread? I’ve
never used threads before…
It might be possible to trap the error within your browser.goto and hand
it back to the join statement without that error?

When Can a join statement throw such error?

8

Joel P. wrote in post #1083551:

Which line is causing the error;

browser.goto(site_url)

or

t.join

?

Error is caused by
t.join
but I guess that thread is somewhat damaged or anything like that when
its using goto.

I am not sure about it… but I want to know why this error happens…
again repeating… it happens at t.join.

Thank you very much again for you help…

9

Joel P. wrote in post #1083554:

Does this help?

Redirecting…

No-no, I went to this link, it catches the error, but the thing is I
dont want to catch the error, rather I want to go to the origin of the
error, and find why this is happening. What is happenning to that
thread? I mean ‘t’ any guess? or possible explanantions?

10

I don’t know enough about threads to be much help; but I would have
thought that if you’ve handled the error caused by the browser timing
out, then you’re passing another error back from that thread which is
causing a second exception.
If you want to include a backtrace in your error handling then that’s
simple enough:

rescue Timeout::Error => e
puts e.backtrace

11

Does this help?

12

Joel P. wrote in post #1083584:

I don’t know enough about threads to be much help; but I would have
thought that if you’ve handled the error caused by the browser timing
out, then you’re passing another error back from that thread which is
causing a second exception.
but then why am getting error at ‘join’
Something happened with that particular thread.
If you want to include a backtrace in your error handling then that’s
simple enough:

rescue Timeout::Error => e
puts e.backtrace

13

You’re using Ruby 1.8.7? I think I’ve seen a few comments online about
thread timeout handling being buggy in that version.

Try a separate install on 1.9.3 and see if the problem still exists.
You should also read up on handling errors both inside the threads, and
in the parent process. For example:

Taken from Ruby - Multithreading

Threads and Exceptions:

If an exception is raised in the main thread, and is not handled
anywhere, the Ruby interpreter prints a message and exits. In threads
other than the main thread, unhandled exceptions cause the thread to
stop running.

If a thread t exits because of an unhandled exception, and another
thread s calls t.join or t.value, then the exception that occurred in t
is raised in the thread s.

If Thread.abort_on_exception is false, the default condition, an
unhandled exception simply kills the current thread and all the rest
continue to run.

If you would like any unhandled exception in any thread to cause the
interpreter to exit, set the class method Thread.abort_on_exception to
true.t = Thread.new { … }
t.abort_on_exception = true