I'm trying create one webservice that consumes yammer with rails, and I'm trying to return message that indicates when action was successfully executed.
around_action :sendOkMessage
rescue_from Exception do |exception|
yammerResult = YammerResult.new
yammerResult.status = 'NOK'
yammerResult.message = exception.inspect
render json: yammerResult
end
The problem is, around_action is always executed (even when error happens), and I don't want this.
What I want is:
No exception raised? Run sendOkMessage, return ok message
Exception raised? Catch exception, return nok message
We could use a flag and toggle it, that is define an instance variable #failed = true in the exception block. And make the first line of the :sendOkMessage. To check the #failed flag, if its true - toggle ito false and return.
def sendOkMessage
#failed = false and return unless #failed
#failed = false
Related
i have a class called PeopleData.
i want to mock call on PeopleData to raise error. so i did this
allow(PeopleData).to receive(:fire_api).with(anything).and_raise(StandardError, "Error Here")
There are two classes call this PeopleData. First is TrafficData, and second is ClimateData.
TrafficData call PeopleData to get some data. I want to test rescue block in TrafficData when there is error on PeopleData call. So i did this
allow(PeopleData).to receive(:fire_api).with(anything).and_raise(StandardError, "Error Here")
expect(TrafficData.call).not_to raise_error
and it is fine. because it was expected. the rescue block is called and return something.
ClimateData class call using parameter data from TrafficData and it also call PeopleData. i want to test ClimateData call and return something without rescue anything.
But the problem is because i allow PeopleData to raise error, it will raise error also on ClimateData
This is what i did
allow(PeopleData).to receive(:fire_api).with(anything).and_raise(StandardError, "Error Here")
expect(TrafficData.call).not_to raise_error
expect do
ClimateData.check_climate!
end.to return(data)
it show error like this
raise StandardError, check_status.to_s
on the line in check_climate method definition.
Question: How to allow PeopleData mocking call ONLY ONCE? only in expect(TrafficData.call).not_to raise_error
so when i call ClimateData.check_climate! it will not raise error
you can do something like this:
values = [proc { raise 'Error Here' }]
allow(PeopleData).to receive(:fire_api).and_wrap_original do |original, *args|
values.empty? ? original.call(*args) : values.shift.call
end
I've been developing Stripe Webhook handler to create/update records depending the values.
It's not really hard, if it's a simple like this below;
StripeEvent.configure do |events|
events.subscribe 'charge.succeeded' do |event|
charge = event.data.object
StripeMailer.receipt(charge).deliver
StripeMailer.admin_charge_succeeded(charge).deliver
end
end
However If I need to store the data conditionally, it could be little messier.
In here I extracted the each Webhook handler and defined something like stripe_handlers/blahblah_handler.rb.
class InvoicePaymentFailed
def call(event)
invoice_obj = event.data.object
charge_obj = retrieve_charge_obj_of(invoice_obj)
invoice = Invoice.find_by(stripe_invoice_id: charge_obj[:invoice])
# common execution for subscription
invoice.account.subscription.renew_billing_period(start_at: invoice_obj[:period_start], end_at: invoice_obj[:period_end])
case invoice.state
when 'pending'
invoice.fail!(:processing,
amount_due: invoice[:amount_due],
error: {
code: charge_obj[:failure_code],
message: charge_obj[:failure_message]
})
when 'past_due'
invoice.failed_final_attempt!
end
invoice.next_attempt_at = Utils.unix_time_to_utc(invoice_obj[:next_payment_attempt].to_i)
invoice.attempt_count = invoice_obj[:attempt_count].to_i
invoice.save
end
private
def retrieve_charge_obj_of(invoice)
charge_obj = Stripe::Charge.retrieve(id: invoice.charge)
return charge_obj
rescue Stripe::InvalidRequestError, Stripe::AuthenticationError, Stripe::APIConnectionError, Stripe::StripeError => e
logger.error e
logger.error e.backtrace.join("\n")
end
end
end
I just wonder how I can DRY up this Webhook handler.
Is there some best practice to approach this or any ideas?
I suggest re-raising the exception in retrieve_charge_obj_of, since you'll just get a nil reference exception later on, which is misleading. (As is, you might as well let the exception bubble up, and let a dedicated error handling system rescue, log, and return a meaningful 500 error.)
a. If you don't want to return a 500, then you have a bug b/c retrieve_charge_obj_of will return nil after the exception is rescued. And if charge_obj is nil, then this service will raise a NPE, resulting in a 500.
if invoice_obj[:next_payment_attempt] can be !present? (blank?), then what is Utils.unix_time_to_utc(invoice_obj[:next_payment_attempt].to_i) supposed to mean?
a. If it was nil, false, or '', #to_i returns 0 -- is that intended? ([]/{} is also blank? but would raise)
Conceptually, this handler needs to issue a state transition on an Invoice, so a chunk of this logic can go in the model instead:
class Invoice < ApplicationRecord
# this method is "internal" to your application, so incoming params should be already "clean"
def mark_payment_failed!(err_code, err_msg, attempt_count, next_payment_at)
transaction do # payment processing usually needs to be transactional
case self.state
when 'pending'
err = { code: err_code, message: err_msg }
self.fail!(:processing, amount_due: self.amount_due, error: err)
when 'past_due'
self.failed_final_attempt!
else
ex_msg = "some useful data #{state} #{err_code}"
raise InvalidStateTransition, ex_msg
end
self.next_attempt_at = next_payment_at
self.attempt_count = attempt_count
self.save
end
end
class InvalidStateTransition < StandardError; end
end
Note: I recommend a formal state machine implementation (e.g. state_machine) before states & transitions get out of hand.
Data extraction, validation, and conversion should happen in the handler (that's what "handlers" are for), and they should happen before flowing deeper in your application. Errors are best caught early and execution stopped early, before any action has been taken.
There are still some other edge cases that I see that aren't really handled.
I have a retry block
def my_method
app_instances = []
attempts = 0
begin
app_instances = fetch_and_rescan_app_instances(page_n, policy_id, policy_cpath)
rescue Exception
attempts += 1
retry unless attempts > 2
raise Exception
end
page_n += 1
end
where fetch_and_rescan_app_instances access the network so can throw an exception.
I want to write an rspec test that it throws an exception first time and doesn't throw an exception second time it gets called, so I can test if the second time it doesn't throw an exception, the my_method won't throw an exeption.
I know i can do stub(:fetch_and_rescan_app_instances).and_return(1,3) and first time it returns 1 and second time 3, but I don't know how to do throw an exception first time and return something second time.
You can calculate the return value in a block:
describe "my_method" do
before do
my_instance = ...
#times_called = 0
my_instance.stub(:fetch_and_rescan_app_instances).and_return do
#times_called += 1
raise Exception if #times_called == 1
end
end
it "raises exception first time method is called" do
my_instance.my_method().should raise_exception
end
it "does not raise an exception the second time method is called" do
begin
my_instance.my_method()
rescue Exception
end
my_instance.my_method().should_not raise_exception
end
end
Note that you should really not be rescuing from Exception, use something more specific. See: Why is it a bad style to `rescue Exception => e` in Ruby?
What you do is constrain the times the message should be received (receive counts), i.e. in your case you can
instance.stub(:fetch_and_rescan_app_instances).once.and_raise(RuntimeError, 'fail')
instance.stub(:fetch_and_rescan_app_instances).once.and_return('some return value')
Calling instance.fetch_and_rescan_app_instances first time will raise RuntimeError, and second time will return 'some return value'.
PS. Calling more than that will result in an error, you might consider using different receive count specification https://www.relishapp.com/rspec/rspec-mocks/docs/message-expectations/receive-counts
This has changed a little in RSpec3.x. It seems the best approach is to pass a block to the receive that defines this type of behaviour.
The following is from the docs suggesting how to create this type of transit failure:
(This errors every other time it is called... But is easy to adapt.)
RSpec.describe "An HTTP API client" do
it "can simulate transient network failures" do
client = double("MyHTTPClient")
call_count = 0
allow(client).to receive(:fetch_data) do
call_count += 1
call_count.odd? ? raise("timeout") : { :count => 15 }
end
expect { client.fetch_data }.to raise_error("timeout")
expect(client.fetch_data).to eq(:count => 15)
expect { client.fetch_data }.to raise_error("timeout")
expect(client.fetch_data).to eq(:count => 15)
end
end
def work_location(application)
if application.contact.work_location.blank? rescue nil
return false
else
return true
end
return false
end
Basically i want to return true or false ....I only want to return true if the work_location is not blank and i need to catch the nil error
Actually this produces a syntax error
syntax error, unexpected modifier_rescue, expecting keyword_then or ';' or '\n'
..._location.blank? rescue nil
def work_location(application)
application.try(:contact).try(:work_location).present?
end
Personally I dislike handling potential nils by doing rescue false because you catch far more than nils: such a rescue rescues all sorts of other errors, for example it will catch NoMethodError, so if you'd typed one of the method names it would squash that error and make it much harder to track down.
Write tests and check both true and false return cases
Shorten code above with:
def work_location(application)
application.contact.work_location.blank? rescue true
end
As far as I can tell, you are creating a helper method here.
I should define a method on application, which you can then use in your views.
The advantage: it is purely object-oriented. An application should know if it has a workplace or not.
Secondly, use try: it will only attempt the given method or block if the receiver is not nil, else it returns nil.
So :
class Application
def has_work_location?
self.contact.try { |c| c.work_location.present? }
end
end
Note that this usage of try only works in rails 3.2, if you are on an older version it does not accept a block. Furthermore nil.present? works and returns falso, so you could write
def has_work_location?
self.contact.try(:work_location).present?
end
Note: because we are adding a method to application, we can safely assume application, so we only need to check that the contact exists anymore.
In your views you can then just write:
<%= #application.contact.workplace if #application.has_work_place? %>
or something similar. Hope this helps.
I'm wondering if writing functions like this is considered good or bad form.
def test(x)
if x == 1
return true
else
return "Error: x is not equal to one."
end
end
And then to use it we do something like this:
result = test(1)
if result != true
puts result
end
result = test(2)
if result != true
puts result
end
Which just displays the error message for the second call to test.
I'm considering doing this because in a rails project I'm working on inside my controller code I make calls to a model's instance methods and if something goes wrong I want the model to return the error message to the controller and the controller takes that error message and puts it in the flash and redirects. Kinda like this
def create
#item = Item.new(params[:item])
if !#item.nil?
result = #item.save_image(params[:attachment][:file])
if result != true
flash[:notice] = result
redirect_to(new_item_url) and return
end
#and so on...
That way I'm not constructing the error messages in the controller, merely passing them along, because I really don't want the controller to be concerned with what the save_image method itself does just whether or not it worked.
It makes sense to me, but I'm curious as to whether or not this is considered a good or bad way of writing methods. Keep in mind I'm asking this in the most general sense pertaining mostly to ruby, it just happens that I'm doing this in a rails project, the actual logic of the controller really isn't my concern.
I would say that methods that return different types (e.g. boolean vs. string vs. numbers) under different circumstances are a bad practice.
If you have some sort of test method that wants to return details of why the test has not passed then you can return a pair of values (an Array) as follows:
def test(x)
if x == 1
return true, "x is fine"
else
return false, "Error: x is not equal to one."
end
end
and then write the section of your controller code as:
valid, message = #item.save_image(params[:attachment][:file])
if !valid
flash[:notice] = message
redirect_to(new_item_url) and return
end
If you're talking about a save_image method that will succeed the majority of the time but may fail and you want to indicate this failure and the reason then I would use exceptions e.g.
def save_image(file)
raise "No file was specified for saving" if file.nil?
# carry on trying to save image
end
and then your controller code would be along the lines of:
begin
result = #item.save_image(params[:attachment][:file])
rescue Exception => ex
flash[:notice] = ex.message
redirect_to(new_item_url) and return
end