Suppose you have an existing app, and want to modify the exception handling for the entire app. It is not possible to wrap the app in a begin/rescue block.
What is a good way to modify the exception handler (to suppress the backtrace) by adding code that runs before the app starts?
begin/rescue are not methods so you can't over-write them. If an exception is raised, several steps will unfold, the first one being...calling .exception on whatever object you passed the exception on. Example:
class A
def exception
p 'I am going to print'
RuntimeError.new('message')
end
end
a = A.new
raise a #=> 'I am going to print' and then runtime error is raised
If you control what you pass to 'raise', then you can pass it an object. The first step after .raise is called is that it calls the .exception method on that object, as you can see from here.
If you don't want the backtrace to show at all in the terminal, use abort instead of raise:
abort 'aborting!' #=> prints 'aborting' to STDERR and then does exit 1 implicitly. No backtrace is shown.
You can wrap the entire app in a method that will do all the exception handling for you:
def exception_handler
puts 'Do whatever you want here before the app starts executing'
yield
rescue
# put the logic of handling errors here
# for example, you could do 'abort 'error occured'' that will make the program stop and not show a backtrace
end
exception_handler do
puts 'My app code goes here'
end
Will print:
Do whatever you want here before the app starts executing
My app code goes here
Let's say your app raises a bunch of ArgumentErrors. What you can do is re-open the class and execute some code before raising:
class ArgumentError
alias_method :real_initialize, :initialize
def initialize(*args) # we're overriding initialize
super(*args)
p 'some code here'
end
end
raise ArgumentError
I use rufus scheduler to run overnight test scripts by calling my functions.
Sometimes I can see "scheduler caught exception:" a message that threw some of my functions. Then scheduler stops execution of following test cases.
How can I make it so scheduler runs all test cases regardless of any exception caught?
This is called "exception swallowing". You intercept an exception and don't do anything with it.
begin
# do some dangerous stuff, like running test scripts
rescue => ex
# do nothing here, except for logging, maybe
end
If you do not need to do anything with the exception, you can omit the => ex:
begin
# do some dangerous stuff, like running test scripts
rescue; end
If you need to rescue Exceptions that don't subclass from StandardError, you need to be more explicit:
begin
# do some dangerous stuff, like running test scripts
rescue Exception
# catches EVERY exception
end
I will sometimes use the fact that you can pass blocks to a method, and I have the method rescue errors, and my code can continue on its way.
def check_block
yield
rescue NoMethodError => e
<<-EOR
Error raised with message "#{e}".
Backtrace would be #{e.backtrace.join('')}
EOR
end
puts check_block {"some string".sort.inspect}
puts check_block {['some', 'array'].sort.inspect}
This first block will go through and rescue with a report returned, the second will operate normally.
This rescue only rescues NoMethodError while you may need to rescue other errors.
The problem is in relation to the radis-rb gem.
The exception is not caught by my rescue block and my app goes down.
My code:
begin
redis = Redis.new
puts "WTF?"
rescue Exception
puts "Exception"
end
If redis is down, the message WTF? is exposed.
It happens with or without the Exception statement.
Why is the exception not raised to my rescue block?
I have solved the problem myself (with help from the community and comments).
The exception occurred in IRB only.
The reason of one is IRB's inspect call when IRB try to print result of Redis.new.
In the script (not IRB), the exception doesn't occur because Redis.new does not raise an exception if the Redis service is down.
This question helped to solve my problem.
Assuming I have a WebCrawler class. There are several errors it can encounter. How should I propagate the errors upward?
Using exceptions:
class WebCrawler
class UrlBadFormatError < StandardError; end
class PageNotFoundError < StandardError; end
class UnauthorizedError < StandardError; end
def crawl(url)
if(! url =~ /some_format/)
raise UrlBadFormatError
response = get(url)
if(response.code == 404)
raise PageNotFoundError
if(response.code == 403)
raise UnauthorizedError
...
end
end
or constants:
class WebCrawler
URL_BAD_FORMAT = 1
PAGE_NOT_FOUND = 2
UNAUTHORZIED = 3
def crawl(url)
if(! url =~ /some_format/)
return URL_BAD_FORMAT
response = get(url)
if(response.code == 404)
return PAGE_NOT_FOUND
if(response.code == 403)
return UNAUTHORZIED
...
end
end
or symbols:
class WebCrawler
def crawl(url)
if(! url =~ /some_format/)
return :url_bad_format
response = get(url)
if(response.code == 404)
return :page_not_found
if(response.code == 403)
return :unauthorized
...
end
end
which is best? or it depends(on what?)
For something which indicates programmer error, such as the wrong type of argument passed to a method, definitely throw an exception. The exception will crash the program, drawing the programmer's attention to the fact that they are using your class incorrectly, so they can fix the problem. In this case, returning an error code wouldn't make sense, because the program will have to include code to check the return value, but after the program is debugged, such errors shouldn't ever happen.
In your WebCrawler class, is it expected that crawl will receive a bad URL as an argument sometimes? I think the answer is probably no. So raising an exception would be appropriate when a bad URL is passed.
When an exception is raised, the flow of execution suddenly "jumps" to the innermost handler. This can be a useful way to structure code when the exception is not expected to happen most of the time, because you can write the "main flow" of your method as simple, straight-line code without including a lot of details about what will happen when some rare error condition occurs. Those details can be separated from the "main flow" code, and put in an exception handler. When an error condition is expected to happen under normal conditions, though, it can be better to put the error handling code inline with the "main flow", to make it clearer what is going on. If the control flow of your program "jumps around" (as is the case when exceptions are used for normal flow control), that means the reader also has to "jump around" in the program text as they are figuring out how it works.
For the other two, I think it is expected that at least sometimes, the HTTP request will return an error code. To determine whether an exception or special return value is the best way to indicate such a condition, I would think about how often those conditions are going to happen under normal usage. Think also about how the client code will read either way. If you use exceptions, they will have to write something like:
urls.map do |url|
begin
crawl(url)
rescue PageNotFoundError
""
rescue UnauthorizedError
""
end
end
(By the way, I think this code example shows something: it might be a good idea if both of your custom exceptions inherit from a common superclass, so you can catch both of them with a single rescue clause if desired.) Or if you use error codes, it would look something like:
urls.map do |url|
response = crawl(url)
if [:page_not_found, :unauthorized].include? response
""
else
response
end
end
Which do you think reads better? It's really up to you. The one thing which you do not want to do is use integer constants for errors. Why use integers? When you print them in a debug trace, you'll have to go look at the list of constants to see what each one means. And using symbols is just as efficient computationally.
Why wouldn't you throw exceptions? They can encapsulate additional information besides just the type, are trivially rescued, and if you're using an IDE, are first-class citizens.
If it's an exception then by all means raises an exception! All three of those cases are, in my opinion, exceptions. While some may argue that 4xx status codes aren't exception-worthy since you may expect them to happen, they are still client errors.
You may also read about Ruby's throw/catch, which offer exception-like behavior for cases where "don't use exceptions for control flow" applies (though I don't think that's the case here).
You should raise errors. If you encounter a malformed URL, or if the page isn't found, or if you weren't authorized to access the page, it means you cannot continue crawling. Raising an error or exception returns from the method and lets the caller deal with the unusual situation.
It should also include information about the error, such as error codes, the URL which resulted in an error and any other relevant information. It can help in deciding how best to handle the error and can later be formatted into a helpful message for the user.
What you should not do, ever, is return numeric error codes. Ruby is not C. Just use symbols instead.
I am against the use of exceptions upon encountering 403s, 404s, malformed urls and similar common occurences on the web. Exceptions are meant for "internal" errors. In the World Wild Web, bad URLs are entirely unexceptional. There should be a method(s) for handling each different URL disease. I would personally return special values as symbols, or some "SpecialCase" objects recording what happened. There is also underused catch...throw statement.
I have a set of cucumber tests that get run on a build server.
I often want faster feedback than the server directly provides and so I watch the console output as it runs. I was wanting a way of identifying any failing test with a single search term so I modified our Around to print "Failed Test" on any exception, but Ruby doesn't seem to be handing the exception back up to the around. I've verified this by having puts statements after the begin ... end.
Does anyone know why this is happening or a way of wrapping any exception thrown from a failing test in a begin?
Around() do |scenario, block|
begin
Timeout.timeout(0.1) do
block.call
end
rescue Timeout::Error => e
puts "Failed Test"
puts caller
rescue Exception => e
puts "Failed Test"
raise e
end
end
Looking at cucumber 1.3.12 it actually rescues any exceptions from scenario steps. So you can't see them in any way without modifying cucumber gem.
See my answer on how to put a debug hook in that place for more information:
https://stackoverflow.com/a/22654786/520567
Have you tried disabling Cucumber's exception capturing with the #allow-rescue tag?
#allow-rescue: Turns off Cucumber’s exception capturing for the tagged scenario(s). Used when the code being tested is expected to raise and handle exceptions.
https://github.com/cucumber/cucumber/wiki/Tags