LINUX.ORG.RU

История изменений

Исправление kaldeon, (текущая версия) :

Легковесные исключения для исключительных ситуаций

panic(41) недостаточно легковесно или недостаточно исключительно?

Чем это лучше обычного if err != nil ?

Контролем со стороны компилятора. Особенно в ситуациях, когда возвращается sum type из 3-4-5 вариантов и ошибочный в них только один.

x, err := foo()

err не обработан, ошибка компиляции. Вот и «контроль». Работает в 90% случаев.

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

Исправление kaldeon, :

Легковесные исключения для исключительных ситуаций

panic(41) недостаточно легковесно или недостаточно исключительно?

Контролем со стороны компилятора. Особенно в ситуациях, когда возвращается sum type из 3-4-5 вариантов и ошибочный в них только один.

x, err := foo()

err не обработан, ошибка компиляции. Вот и «контроль». Работает в 90% случаев.

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

Исправление kaldeon, :

Легковесные исключения для исключительных ситуаций

panic(41) недостаточно легковесно или недостаточно исключительно?

Контролем со стороны компилятора. Особенно в ситуациях, когда возвращается sum type из 3-4-5 вариантов и ошибочный в них только один.

x, err := foo()

err не обработан, ошибка компиляции. Вот и «контроль». Работает в 90% случаев.

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

Исправление kaldeon, :

Легковесные исключения для исключительных ситуаций

panic(41) недостаточно легковесно или недостаточно исключительно?

Контролем со стороны компилятора. Особенно в ситуациях, когда возвращается sum type из 3-4-5 вариантов и ошибочный в них только один.

x, err := foo()

err не обработан, ошибка компиляции. Вот и «контроль». Работает в 90% случаев.

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

Исправление kaldeon, :

Легковесные исключения для исключительных ситуаций

panic(41) недостаточно легковесно или недостаточно исключительно?

Контролем со стороны компилятора. Особенно в ситуациях, когда возвращается sum type из 3-4-5 вариантов и ошибочный в них только один.

x, err := foo()

err не обработан, ошибка компиляции. Вот и «контроль». Работает в 90% случаев.

Исправление kaldeon, :

Легковесные исключения для исключительных ситуаций

panic(41) недостаточно легковесно или недостаточно исключительно?

Контролем со стороны компилятора. Особенно в ситуациях, когда возвращается sum type из 3-4-5 вариантов и ошибочный в них только один.

x, err := foo()

err не обработан, ошибка компиляции. Вот и «контроль». Работает в 90% случаев. Оставшиеся 10% — это уже пьянство, тупость и прочее, то есть проблемы, которые сложная типизация не решит, а скорее ухудшит.

sum type из 3-4-5 элементов — это straw man, поскольку такая практика не является нормой в языке. Можно было бы сказать, что если в языке уже есть sum type, то проверка ошибок должна быть на уровне (чтобы не сломать ногу в «3-4-5» элементах), но к Go это неприменимо.

Исправление kaldeon, :

Легковесные исключения для исключительных ситуаций

panic(41) недостаточно легковесно или недостаточно исключительно?

Контролем со стороны компилятора. Особенно в ситуациях, когда возвращается sum type из 3-4-5 вариантов и ошибочный в них только один.

x, err := foo()

err не обработан. Вот и проверка со стороны компилятора. Работает в 90% случаев. Оставшиеся 10% — это уже пьянство, тупость и прочее, то есть проблемы, которые сложная типизация не решит, а скорее ухудшит.

sum type из 3-4-5 элементов — это straw man, поскольку такая практика не является нормой в языке. Можно было бы сказать, что если в языке уже есть sum type, то проверка ошибок должна быть на уровне (чтобы не сломать ногу в «3-4-5» элементах), но к Go это неприменимо.

Исходная версия kaldeon, :

Легковесные исключения для исключительных ситуаций

panic(41) недостаточно легковесно?

Контролем со стороны компилятора. Особенно в ситуациях, когда возвращается sum type из 3-4-5 вариантов и ошибочный в них только один.

x, err := foo()

err не обработан. Вот и проверка со стороны компилятора. Работает в 90% случаев. Оставшиеся 10% — это уже пьянство, тупость и прочее, то есть проблемы, которые сложная типизация не решит, а скорее ухудшит.

sum type из 3-4-5 элементов — это straw man, поскольку такая практика не является нормой в языке. Можно было бы сказать, что если в языке уже есть sum type, то проверка ошибок должна быть на уровне (чтобы не сломать ногу в «3-4-5» элементах), но к Go это неприменимо.