Hi guys,
This is more of an workflow engineering question rather than a question
about Ruby. I have a Sinatra + Datamapper webapp in which I have little
to no exception handling. Recently a bug was found in the app that
resulted in a 500 server error, which is obviously no good.
Currently, I validate data and make sure everything is sound in my
controllers. If I do detect anything wrong, I send back the user to the
previous page with an error message. On each page my app determines if
there are any errors, and if there are, it displays it in an appropriate
place. In essence, I have a method like:
back :error, 'You divided by zero!'
...Which results in something like...
domain.com/page?error=You+divided+by+zero!
I think this is a pretty decent way about displaying the issue back to
the user, but this is not my major concern. My concern is:
Should I rely on errors like these, exceptions, or combination of both?
If I do go with one or the other - what is the most appropriate place to
catch the bug in? As I mentioned before, my app uses Datamapper. Let's
say, for example, that I have a Car resource. A car object can run.
car = Car.first(:make => 'Nissan', :year => '2007', :model => 'Maxima')
car.run
What if a car can't run? Here are some possible scenarios that I can
think of to solve the problem:
1.
# catch an exception inside the model - inside the run method
# handle errors appropriately there
car.run
2.
# raise an exception inside the run method but
# handle the exception in the controller
begin
car.run
rescue
back :error, 'Car is broken'
end
3.
# screw exceptions... make sure the car runs first
if car.can_run?
car.run
else
back :error, 'Car is broken'
end
So... Is it best to handle exceptions as close to the core as possible,
as close as it can be detected, or is it best to avoid throwing
exceptions all over the place, and do it on a minimal basis?
Thanks guys,
Mateusz
···
--
Posted via http://www.ruby-forum.com/.