Week2 Day 9

gistfile1.md

Week 2 Day 9

Pass the Test

Hierarchy of Exceptions

Run tests: $ rspec spec/bundle_i_spec.rb

I got it to pass after feeling like the ground beneath me had shifted and I was hanging onto a thread of knowing what I was even trying to do.

Hint 1 - Jessica @jendiamond I talked to Andre and he says this spec goes in spec/other/cli_dispatch_spec.rb. Please move it to there! It is a CLI Dispatch because the command line interface is trying to forward the argument 'i' to the proper command.

Hint 2 - Joyce The order matters. The hierarchy of code.

• I read:
  http://www.ruby-doc.org/docs/ProgrammingRuby/
  http://ruby.bastardsbook.com/chapters/exception-handling/
  http://rubylearning.com/satishtalim/ruby_exceptions.html

• But it wasn't until I re-read:
  http://www.mikeperham.com/2012/03/03/the-perils-of-rescue-exception/

"So remember, your application errors should be subclasses of StandardError and if you want to catch everything, just stick will plain old “rescue => ex”. Your application will behave better for it.

• That I Googled: subclasses of StandardError and found:
  http://www.codeotaku.com/journal/2009-08/ruby-standard-error/index

Direct descendants of Exception:

NoMemoryError
ScriptError
StandardError
SignalException
fatal
SystemExit

Direct descendants of StandardError:

SystemStackError
LocalJumpError
IOError
RegexpError
ZeroDivisionError
ThreadError
SystemCallError
SecurityError
RuntimeError
NameError
RangeError
IndexError
ArgumentError
TypeError

---

I got it to pass!

$ rspec spec/bundle_i_spec.rb

Run options:
include {:focused=>true}
exclude {:ruby=>"1.8", :realworld=>true, :sudo=>true}

All examples were filtered out; ignoring {:focused=>true}

bundle i error
should not raise an error

Finished in 1.31 seconds
1 example, 0 failures

---

Other Things I Learned

• empty? is a method some objects respond to. You need to check the documentation for each case. For example, and empty array is one that is not nil (it is an array right?) and has no elements. An empty string is one that is not nil (it is a string right?) and has no bytes, nothing.

• I did this yesterday; I now realize why this is important.
  irb: StandardError.ancestors => [StandardError, Exception, Object, Kernel, BasicObject]

Before it was fixed it looked like this

bundle i
/var/lib/gems/1.9.1/gems/bundler-1.3.5/lib/bundler/vendor/thor.rb:405:in normalize_task_name': Ambiguous task i matches [init, inject, install] (ArgumentError) from /var/lib/gems/1.9.1/gems/bundler-1.3.5/lib/bundler/vendor/thor.rb:321:in dispatch'
from /var/lib/gems/1.9.1/gems/bundler-1.3.5/lib/bundler/vendor/thor/base.rb:434:in start' from /var/lib/gems/1.9.1/gems/bundler-1.3.5/bin/bundle:20:in block in <top (required)>'
from /var/lib/gems/1.9.1/gems/bundler-1.3.5/lib/bundler/friendly_errors.rb:3:in with_friendly_errors' from /var/lib/gems/1.9.1/gems/bundler-1.3.5/bin/bundle:20:in <top (required)>' from /usr/local/bin/bundle:19:in load' from /usr/local/bin/bundle:19:in

'
should not raise an error (FAILED - 1)

Previously when I ran the test $ rspec spec/bundle_i_spec.rb it looked like this:

Failures:

1. bundle i error should not raise an error
   Failure/Error: expect(err).to be_empty
   expected empty? to return true, got false

   ./spec/bundle_i_spec.rb:6:in `block (2 levels) in <top (required)>'

Finished in 1.16 seconds
1 example, 1 failure

Failed examples:

rspec ./spec/bundle_i_spec.rb:4 # bundle i error should not raise an error