Очень часто программисты не думают о чрезвычайных ситуациях. Особенно печально, когда это не разработчики приложений, а авторы библиотек и фреймворков.

Например, когда я готовил этот материал, я спросил в чате Effector, как система ведет себя при возникновении исключений. На что мне ответили, что в чистых функциях не должно быть исключений (кстати, исключения на самом деле не противоречат чистоте, но это другая история), и если ты их допустил, то ты сам дурак. Когда я спросил, знает ли автор, как его библиотека поведет себя в чрезвычайной ситуации, меня обвинили в токсичности и забанили.

Ошибок тоже не должно быть, как и других неприятностей в жизни, однако они иногда случаются. Вина ли это программиста, браузера, его расширений, операционной системы, звездного ветра — неважно. Нужно уметь принимать удар и не прятать голову в песок. Но в разных реактивных библиотеках мы столкнемся с разным поведением…

? Unstable: Нестабильная работа
⛔ Stop: Остановка работы
? Revert: Откат к стабильному состоянию
? Store: Индикация ошибки и ожидание восстановления

? Unstable: Нестабильная реактивность

Часто при возникновении исключения приложение переходит в неконсистентное состояние, что приводит к нестабильной работе.

В примере, допустим, в имя закрался некорректный codepoint. И, скажем, попытка взять длину строки в этом случае приводит к исключению. Пример довольно синтетический, позже я покажу более реалистичные, а пока так.

Итак, при вычислении инварианта произошло исключение, из-за чего runtime не обновил Count. В результате все состояния разделились на 2 подграфа, которые сами по себе консистентны, но уже не согласованы друг с другом.

⛔ Stop: Остановка реактивности

Не менее странное решение — просто прекратить работу, как, например, делает RxJS. Если в потоке где-то возникает исключение, то все последующие потоки завершаются и больше не работают.

Эта стратегия подходит для одиночной задачи — либо ты ее выполняешь, либо падаешь с ошибкой. Но реактивность предназначена для долгоживущих систем, которые постоянно что-то отображают. Это значит, что если реактивность сломается, приложение просто сломается без уведомления пользователя.

Более того, оно сломается только наполовину. А чтобы восстановить работу, придется перезапускать либо все приложение, либо хотя бы эту половину.

Случай из жизни: на моем этаже в отеле поселилась толпа спортсменов. И это ребята под 100 кг чистого мяса. И вот как-то утром мы втиснулись с ними в лифт, что предсказуемо привело к перегрузке. Лифт поднял лапки и сказал “все”.

Ну, ладно, пара вышла — ничего не произошло. Половина вышла — все равно ничего. Все вышли — лифт все равно не заработал. И нам всем пришлось бежать по лестнице. Думаю, софт для этого лифта писали на RxJS, не иначе.

? Revert: Откат к стабильному состоянию

Некоторые библиотеки, в принципе, не допускают неконсистентности, пересчитывая инварианты в рамках транзакции. Так что если что-то идёт не так, все состояния откатываются к последнему консистентному.

Формально звучит неплохо. Но для пользователя это ужасное поведение, потому что из-за одной дряной овцы где-то в углу приложения, которая постоянно выбрасывает исключения, все приложение встает колом и никак не реагирует на действия пользователя. Или проще говоря — оно крепко зависает. Что нехорошо.

? Store: Индикация ошибки и ожидание восстановления

Гораздо практичнее рассматривать ошибку как возможный результат вычисления наряду с возвращаемым значением.

Здесь все состояния, зависящие от некорректного, тоже помечаются как некорректные. И система рендеринга может автоматически показывать индикатор ошибки для частей приложения, которые не удалось обновить. Либо можно поймать исключение и нарисовать свое красивое сообщение. В любом случае пользователь поймет, что происходит и что на сломанную часть приложения полагаться не стоит. Но другие части можно продолжать использовать.

Хотя часть приложения сломана, состояние приложения остается консистентным. Потому что сообщение об ошибке на выходе согласовано с некорректным значением на входе.

При этом устранение причины сбоя автоматически восстановит корректную работу этой части приложения. Без дополнительных действий со стороны программиста!

Именно эта стратегия и используется в $mol_wire - самом продвинутом реактивном рантайме.

Исключения в $mol_wire

Реактивное состояние может принимать один из 3 возможных типов значений:

• Result — фактическое валидное значение.

• Error — информация об исключении.

• Promise — обещание, что скоро появится либо значение (Result), либо объяснение, почему его нет (Error).

Эти значения могут поступать следующими способами:

• return — значение, возвращаемое функцией.

• throw — прерывание выполнения.

• put — прямое запись значения в кэш.

В данном случае неважно, каким способом мы доставили значение — оно записывается в кэш. При доступе к состоянию поведение зависит только от типа значения:

• Ошибки и промисы выбрасываются через throw.

• Остальные значения возвращаются через return.

class MyModel extends Object {

  // throws Promise or Error
  @act fetchJSON( url: string ): object {
    return fetch( url ).then( resp => res.json() ) // return Promise
  }

  // throws Promise
  @mem profile(): { name: string } {
    try {
      return this.fetchJSON( '/profile' ).user
    } catch( error ) {
      if( 'then' in error ) throw error // catch & throw Promise
      return { name: 'unknown' }
    }
  }

  // throws Promise
  @mem name(): string {
      return this.profile().name // bypass Promise
  }
  
}

То есть реактивная мемоизация методов не совсем прозрачна: если вы вернете экземпляр Error, он все равно будет выброшен позже, а если вы выбросите, например, строку, она все равно будет возвращена позже. Получается своего рода нормализация поведения.

Конечно, можно было бы сделать прозрачное поведение, но в JS у нас уже есть нормализация с асинхронными функциями: что бы мы ни возвращали или кидали, они всегда возвращают промис. А промисы, кстати, в нашем случае нужно не возвращать, а выбрасывать, но об этом в другой раз.

А пока, подписывайтесь на что-нибудь, вступайте во что-то там, и держите руку на пульсе вот этого вот.