• Още за класовите методи
• Замразяване на обекти
• Изключения
• Специален гост втория час – Mislav Marohnić

• Качено е на сайта
• Имате време до сряда по обяд

• Условието на втора задача изисква създаването на класов метод
• Миналия път ви показахме един от начините да дефинирате такъв
• Този начин не е единствен и не е "каноничният"
• Без да навлизаме в детайли, днес ще ви покажа двата други начина

Този начин е еквивалентен на предишния слайд:

class TodoList
  def self.parse(todos_string)
    # Solution lost.
  end
end

Това работи, понеже:

• Тялото на класа е изпълним код
• Както във всеки друг контекст в Ruby, и там имаме self
• self и TodoList в тялото на класа са едно и също

class TodoList
  class << self
    def parse(todos_string)
      # Solution lost.
    end
  end
end

• Какъв е този синтаксис и защо работи, ще си говорим по-нататък

• Първият начин не се ползва (def ClassName.method_name() end)
• При дефиниране на един, максимум два класови метода, ползваме втория начин
• При дефиниране на повече от един класов метод, обикновено ползваме третия начин
• За справка – ръководството по стил

Преди да продължим със следващата тема.

• Реално превръща mutable-обекти в immutable
• Замразяването става с Object#freeze
• Можете да проверите дали обект е замразен с Object#frozen?
• Веднъж замразен, даден обект не може да бъде размразен
• Не можете да променяте вече замразени обекти
• Често се ползва, когато присвоявате mutable-типове на константи

Тъй като низовете в Ruby са mutable, всяко срещане на низ = нов обект:

''.object_id                 # 548088440
''.object_id                 # 548088190
''.object_id == ''.object_id # false

• Това е performance проблем
• Символите го решават, но те не са низове (не се garbage collect-ват)
• Последното води до опасност от DoS-атаки (memory leaks)

class HTTP
  attr_reader :method
  METHOD_POST = 'POST'.freeze

  def post?
    method == METHOD_POST
  end
end

Това е досадно. Затова в Ruby 2.1 има и по-добро решение.

• "Chunky bacon".freeze няма да работи, защото пак ще създава нов обект
• Единственото решение - синтаксис
• "Chunky bacon"f ще създаде замразен обект от тип низ
• Ако вече има такъв обект, с такова съдържание, той ще бъде преизползван
• Синтаксисът е наличен от Ruby 2.1 нататък

Преди да продължим със следващата тема.

• Всички знаем какво са изключения.
• Нали?
• Метод за обработка на грешки.
• Позволява разделяне на обработката от останалия код.
• Все хубави неща.

• Накратко, двойка клас и низ.
• Съответно, тип на изключението и съобщение за грешка.
• Класовете за изключения са в йерархия.
• Два важни типа Exception и StandardError.
• StandardError < Exception.

Object
+-- Exception
   +-- NoMemoryError
   +-- ScriptError
   |   +-- SyntaxError
   |   +-- LoadError
   +-- SecurityError
   +-- StandardError
       +-- ArgumentError
       +-- IndexError
       |   +-- KeyError
       |   +-- StopIteration
       +-- NameError
       |   +-- NoMethodError
       +-- RuntimeError
       +-- TypeError 

После ще видим пълната.

rescue хваща "само" наследници на StandardError, ако не сме указали друго:

Object
+-- Exception
   +-- NoMemoryError
   +-- ScriptError
   +-- StandardError
       +-- ArgumentError
       +-- NameError
       |   +-- NoMethodError
       +-- RuntimeError 

Припомняне KeyError < IndexError

$eh = 'foo'

begin
  raise KeyError, 'Is there - is there balm in Gilead?'
rescue IndexError => ex
  $eh = 'index'
rescue KeyError => ex
  $eh = 'key'
end

$eh    # "index"

Изпълнява се първия rescue, за който изключението е kind_of? типа.

Динамичните езици обикновено ползват прости правила

• "Първото отговарящо" е по-просто от "по-подходящото".
• Или от "всички отговарящи".
• Аналогичен случай с модулите.
• Два дизайн принципа: KISS и PLOA.
• Keep it simple, stupid!
• Principle of least astonishment.
• Важат с пълна сила за кода, който пишете.

Кодът в ensure клаузата се изпълнява винаги.

begin
  raise 'tell me - tell me, I implore!' if rand(2).zero?
ensure
  puts '????? ??? ?????, "?????????"'
end

• rand(2).zero? връща true или false, 50 на 50.
• Подходяща е за затваряне на ресурс, като отворен файл.
• Някой сеща ли се какво има на мястото на въпросителните?

else клаузата се изпълнява когато няма възникнало изключение.

begin
  launch_nukes
rescue
  puts 'Uh-oh! Something went wrong :('
else
  puts 'War... War never changes'
end

• Обърнете внимание, че launch_nukes няма удивителна.
• Дори да е опасен, няма "по-безопасна" версия.
• Не заслужава допълнителна пунктуация.

В случай, че ползвате rescue в метод така:

def execute
  begin
    potentially_dangerous
  rescue SomeException => e
    # Handle the error
  ensure
    # Ensure something always happens
  end
end

По-добре е да го запишете без begin/end, което е еквивалентно на предното:

def execute
  potentially_dangerous
rescue SomeException => e
  # Handle the error
ensure
  # Ensure something always happens
end

Ако възникне изключение при обработка друго, старото се игнорира и се "вдига" новото.

begin
  raise KeyError
rescue
  raise TypeError
  puts "I'm a line of code, that's never executed ;("
end

raise в rescue клауза "вдига" същото изключение, което се обработва.

begin
  raise KeyError, 'But high she shoots through air and light'
rescue
  puts 'Whoops'
  raise
end

• rescue може да се ползва като модификатор.
• Ако възникне изключение, rescue връща стойността отдясно.
• Внимавайте. Така може да хващате само StandardError.

[].fetch(1) rescue 'baba' # "baba"

raise type, message всъщност извиква type.exception(message) за да конструира изключение.

class Thing
  def exception(message)
    NameError.new(message)
  end
end

thing = Thing.new
raise thing, 'whoops' # error: NameError

Може да разделим изключенията на два вида.

• Такива, които обикновено ще хващаме с rescue.
• Такива, които няма да хващаме.

За първите обикновено създаваме клас. За вторите обикновено ползваме raise.

• Някой ще хваща ли това изключение въобще?
• Ако не, не правете нов клас.
• Клиентът може ли да предвиди дали ще възникне изключение?
• Ако да, не го принуждавайте да го ползва.
• Не принуждавайте клиента да знае за изключенията ви, освен когато нямате избор.
• Например писане по мрежата - няма как да знаете предварително.

• Много рядко някой иска да хване KeyError или IndexError. Защо?
• Ако пишете библиотека, помислете за базов клас на нейните изключения.
• Look Before You Leap и Better Ask Forgiveness Than Permission.
• Не ползвайте изключенията за control flow. В Ruby има друга конструкция.

• Сходни на raise и rescue.
• Не ползват изключения.
• Служат за предаване на информация по стека.

def iterate_pairs(hash)
  hash.values.each { |array| iterate_values array }
end

def iterate_values(array)
  array.each do |item|
    if item == 'Nemo'
      puts 'Found Nemo!'
      throw :done
    end
  end
end

animals = {cats: %w[Simba], fish: %w[Crispy Nemo], boars: %w[Pumba]}
catch(:done) { iterate_pairs(animals) }

Този пример е доста синтетичен.

• catch приема символ и блок.
• Нещо в блока може да извика throw със същия символ.
• Когато това стане, Ruby започва да търси обратно по стека до съответния catch.
• Когато бъде намерен, изпълнението продължава след catch-а.
• throw взема допълнителен аргумент, който е върнатата стойност на catch.
• Ако няма throw, стойността на catch е последния оценен израз.

• http://fmi.ruby.bg/
• @rbfmi