I have a class called RemoteError with a self.fatal method on it. This methods job is basically to catch an exception, send the details of the exception to a server and then propagate the exception in order to kill the program.
class RemoteError
def initialize(label, error)
#label = label
#error = error
end
def self.fatal(label, error)
object = new(label, error)
object.send
raise error
end
def send
# send the error to the server
end
end
I'm trying to write tests for the RemoteError.fatal method. This is difficult because of the call to raise within the method. Every time I run my tests, raise obviously raises an exception and I can't test that send was called.
describe "fatal" do
it "should send a remote error" do
error = stub
RemoteError.stub(:new) { error }
error.should_receive(:send)
RemoteError.fatal(stub, stub)
end
end
Is there a way that I can stub or somehow circumvent raise for this specific test?
You could wrap the method that raises the error in a lambda...
it "should send a remote error" do
...
lambda { RemoteError.fatal(stub, stub) }.should raise_error(error)
end
This essentially allows the method to be called, and you get the return value or raised error from it, which you then assert against with .should raise_error(error). This also makes is so that if no error is raised from that call, the test will fail normally.
To say it another way, you don't need, nor want, to stub raise. Simply wrap it in a lambda and your code will continue to execute, you should be able to make sure that your message is sent, and your test won't exit/crash.
In your tests you are testing the method that raises an error and this is an expected result of method execution. You should write expectation for exception with this syntax:
lambda{ RemoteError.fatal(stub, stub) }.should raise_error
In this case your spec will fail if exception won't be raised and also will fail if all other expectations (like should_receive(:sen)) won't be met.
Related
I'm new to ruby. Trying to write a test that passes when an exception is raised, for example:
def network_data_unavailable
assert_raise StandardError, NetworkSim.sim(totalUse, 3, "five")
end
Those inputs will cause a StandardError to be raised but my test still fails. Any help on what I'm missing here?
First of all, I think the method you're looking for is assert_raises, not assert_raise. Then you need to call it correctly by giving it a block:
#assert_raises(*exp) ⇒ Object
Fails unless the block raises one of exp. Returns the exception matched so you can check the message, attributes, etc.
[...]
assert_raises(CustomError) { method_with_custom_error }
You want to say:
assert_raises StandardError do
NetworkSim.sim(totalUse, 3, "five")
end
so that assert_raises can call the block after it has set up the exception handling. They way you're calling it, NetworkSim.sim will be called while building the argument list to assert_raises and the exception will be raised before assert_raises can do anything to catch it.
I have a function in ruby
def mark_completed
var_a = self.a
self.check_something
end
The other function is
def check_something(query = nil)
raise 'Some_exception' if condition_a_satisfy?
return true
end
See , the function check_something is raising exception , What I want is : - "To catch the exception and return false somehow"
How can i do it?
Note : - I cannot change my check_something function.
Rescue RuntimeError in #mark_completed
When you call Kernel#raise with a string, you're actually raising the default exception, which is RuntimeError. You should catch that explicitly to avoid catching other exceptions that descend from StandardError unintentionally, or courting disaster by rescuing Exception which is almost never a good idea. For example:
def mark_completed
self.check_something
rescue RuntimeError
false
end
This will solve the question you asked in a controlled way, but deliberately side-steps the question of whether raising exceptions is the right thing for the code to do in the first place, or whether other refactorings are possible.
This does involve changing the method, but this could still be useful to know.
Hi, I think you’re o looking for a try and catch statement in ruby. This will run Code if there is no error or exception, and if there is it will run specified Code.
For an example:
def check_something(query = nil)
begin
# to execute with no exceptions
rescue Exception
# to execute when you hit an exception
ensure
# to execute always
end
In ruby you can resque, multiple excetions like this:
begin
...
rescue Exception1, Exception2
...
rescue Exception1
...
rescue Exception2
...
end
But I do not know how to raise multiple exceptions:
1] pry(main)> ? raise
From: eval.c (C Method):
Owner: Kernel
Visibility: private
Signature: raise(*arg1)
Number of lines: 13
With no arguments, raises the exception in $! or raises
a RuntimeError if $! is nil.
With a single String argument, raises a
RuntimeError with the string as a message. Otherwise,
the first parameter should be the name of an Exception
class (or an object that returns an Exception object when sent
an exception message). The optional second parameter sets the
message associated with the exception, and the third parameter is an
array of callback information. Exceptions are caught by the
rescue clause of begin...end blocks.
raise "Failed to create socket"
raise ArgumentError, "No parameters", caller
Or I cannot figure this in the raise doc
The purpouse of this is that I have an API call, this call tries to create an object in the API.
Then the APi could return all the problems in the object, from Activerecord Validators, So I can get thinks like that such as:
422 "The Item is not even","The Item needs too be bigger than 100"
422 "The Item is not even"
200 OK "Item created"
500 "I'm a tee pot
The idea is to capture this and raise exceptions like this
Begin
API CALL
rescue ItemnotEven,ItemnotBigger
do something
retry if
rescue ItemnotEven
retry if
rescue Connection error
Log cannot connect
end
Exceptions shouldn't be used for validations. Basically you shouldn't traverse the stack for validations in general.
What you fundamentally are doing is:
X is top level and can handle everything. X calls Y. Y calls Z. Z performs validations and does something after that, raising an exception if validation failed.
What you should be doing is:
X calls Y. Y calls V and X. V performs validations and returns result based on if the thing was valid. Y doesn't get to call X if V said the thing was invalid. Y propagates the invalidness or the successful result to X. X does what it would have done with if/else on the validity, rather than rescue.
But lets say you really want to do it. You should use throw/catch instead:
def validate_date(date)
errors = []
errors << 'Improper format' unless date.match?(/^\d{2}-\d{2}-\d{4}$/)
errors << 'Invalid day' unless date.match?(/^[0-3]\d/)
errors << 'Invalid month' unless date.match?(/-[12]\d-/)
errors << 'Invalid year' unless date.match?(/[12][90]\d{2}$/)
throw(:validation, errors) unless errors.empty?
end
def invoke_validation_and_do_stuff(date)
validate_date(date)
puts "I won't be called unless validation is successful for #{date}"
end
def meaningless_nesting(date)
invoke_validation_and_do_stuff(date)
end
def more_meaningless_nesting(date)
meaningless_nesting(date)
end
def top_level(date)
validation_errors = catch(:validation) do
more_meaningless_nesting(date)
nil
end
if validation_errors
puts validation_errors
else
puts 'Execution successful without errors'
end
end
top_level '20-10-2012'
# I won't be called unless validation is successful for 20-10-2012
# Execution successful without errors
top_level '55-50-2012'
# Invalid day
# Invalid month
I don't think you can raise multiple exceptions, it'll raise the first exception it finds and will be caught by the innermost rescue statement if multiple exist or depends on the type of exception you raise and type of rescue
No such concept exists, in any language that I am aware of.
You can raise a single exception consecutively, but not raising multiple exceptions at one time, and even if working on multiple threads to raise "simultaneously", it is still a single exception being raised on different control flows.
When an exception is raised, control flow goes to that exception. You have two options: do something about it, or crash. There is no third option, and no separate control flow popped up and is continuing on until this exception is dealt with accordingly.
If you want to see multiple failures as you stated in a comment, then you will still be doing it one at a time, as is how they would be raised. Exception gets raised, you inspect, log, do whatever, suppress it, and see the next if one gets raised for something else.
If you are asking how multiple unhandled exceptions can be raised, then it really doesn't make sense. It is akin to asking how to be in two places at once.
I am trying to improve my Ruby skills by catching exceptions. I want to know if it is common to reraise the same kind of exception when you have several method calls. So, would the following code make sense? Is it ok to reraise the same kind of exception, or should I not catch it on the process method?
class Logo
def process
begin
#processed_logo = LogoProcessor::create_image(self.src)
rescue CustomException
raise CustomException
end
end
end
module LogoProcessor
def self.create_image
raise CustomException if some_condition
end
end
Sometimes we just want to know an error happened, without having to actually handle the error.
It is often the case that the one responsible for handling errors is user of the object: the caller. What if we are interested in the error, but don't want to assume that responsibility? We rescue the error, do whatever we need to do and then propagate the signal up the stack as if nothing had happened.
For example, what if we wanted to log the error message and then let the caller deal with it?
begin
this_will_fail!
rescue Failure => error
log.error error.message
raise
end
Calling raise without any arguments will raise the last error. In our case, we are re-raising error.
In the example you presented in your question, re-raising the error is simply not necessary. You could simply let it propagate up the stack naturally. The only difference in your example is you're creating a new error object and raising it instead of re-raising the last one.
This will raise the same type of error as the original, but you can customize the message.
rescue StandardError => e
raise e.class, "Message: #{e.message}"
I had the same question as in the comment thread here, i.e. What if the line before (re)raise fails?
My understanding was limited by the missing knowledge that the global variable of $! is "kinda garbage collected" // "scoped to its functional context", which the below example demonstrates:
def func
begin
raise StandardError, 'func!'
rescue StandardError => err
puts "$! = #{$!.inspect}"
end
end
begin
raise StandardError, 'oh no!'
rescue StandardError => err
func
puts "$! = #{$!.inspect}"
raise
end
The output of the above is:
$! = #<StandardError: func!>
$! = #<StandardError: oh no!>
StandardError: oh no!
from (pry):47:in `__pry__'
This behavior is different than how Python's (re)raise works.
The documentation for Exception states:
When an exception has been raised but not yet handled (in rescue,
ensure, at_exit and END blocks), two global variables are set:
$! contains the current exception.
$# contains its backtrace.
So these variables aren't true global variables, they are only defined inside the block that's handling the error.
begin
raise
rescue
p $! # StandardError
end
p $! # nil
A slightly better way to do the same thing as FreePender is to use the exception method from the Exception class, which is the ancestor class to any error classes, like StandardError, so that the method is available to any error classes.
Here the method's documentation that you can find on ApiDock:
With no argument, or if the argument is the same as the receiver, return the receiver. Otherwise, create a new exception object of the same class as the receiver, but with a message equal to string.to_str.
Now let's see how it works:
begin
this_will_fail!
rescue Failure => error
raise error.exception("Message: #{error.message}")
end
Adding to above answers here:
In some applications you may need to log the error twice.
For example exception need to be notified to monitoring tools like
Nagios/Newrelic/Cloudwatch.
At the same time you may have your own kibana backed summary logging
tool, internally for your reference.
In those cases you might want to log & handle the errors multiple times.
Example:
begin
begin
nil.to_sym
rescue => e
puts "inner block error message: #{e.message}"
puts "inner block backtrace: #{e.backtrace.join("\n")}"
raise e
end
rescue => e
puts "outer block error message: #{e.message}"
puts "outer block backtrace: #{e.backtrace.join("\n")}"
end
I am using puts here, for your the ease of verifying this code in
rails console, in actual production you may need to use rails logger
I have a method that takes block of code as an argument. The problem is: how to test using RSpec if this method called the block?
The block may be evaluated in any scope the method needs, not necessarily using a yield or block.call. It be passed to another class, or evaluated it in an anonymous class object or somewhere else. For the test to pass it is enough to evaluate the block somewhere as a result of the method call.
Is there a way to test something like this using RSpec?
See also this for more complex case with lets and mocks.
I like using throw instead of raise for this sort of problem, because it can't be rescued be an arbitrary rescue handler. So it might look like this:
my_proc = proc { throw :my_proc_was_called }
expect {
my_proc.call
}.to throw_symbol :my_proc_was_called
I usually do something like
a = 1
b.go { a = 2}
a.should == 2
Thanks to Dave Newton's suggestion in the comment above I did something like this:
it "should run block defining the node" do
message="This message is raised if block is properly evaluated."
expect do
node do
raise message
end
end.to raise_error message
end
In case of error this prints message:
Failure/Error: expect do
expected Exception with "This message is raised if block is properly evaluated." but nothing was raised
Which I find informative enough.
Thanks again for help!