Для Java в принципе тоже это характерно, но там хотя бы не до такой степени имбецилы, чтобы хотя бы стектрейсе не написать, что конкретно произошло.

ему столько десятилетий, что может и сам

...вспомнилось из perldoc autodie

bIlujDI' yIchegh()Qo'; yIHegh()!
It is better to die() than to return() in failure.
        -- Klingon programming proverb.

не узнаю второе и третье слово, какой-то очень сложный клингонский

это древнеклингонский

Если что, этот вариант плох тем, что у вас в прод системе, в которой будет выполняться этот контейнер, будет gcc со всеми вытекающими последствиями.

Что бы этого не было, нужно использовать multistage build`ы - а именно, после
RUN carton install --deployment

надо начать новый стейдж с чистого базового образа и скопировать то, что накомпилил carton.

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

Если что, использовать

```
use warnings FATAL => 'all';
```

не рекомендуется прямо в perldoc warnings:

    
NOTE: FATAL warnings should be used with care, particularly "FATAL =>
    'all'".

Я один раз на это напарывался - вместо увеличения падаемости, один стрёмный случай просто "проглотился" - ни варнингов, ни падения.

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

Видать не видел ты систем, где каждый чих логируется :)

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

Сотни мегабайт?)) Support data у dell powerstore, к примеру, весит примерно гига полтора. И это логи только за последние несколько часов работы

Речь о сотнях мегабайт в секунду :) При разработке стратегии обработки ошибок надо учитывать возможность подобных ситуаций..

Так он генерит сотни мегабайт в секунду, там же сжатые полтора гига

Ну, в общем, надо не прощёлкать, когда эти 100MB/s заполнят продовые диски или сеть.
Сообщать об ошибках лучше аккуратно

Да, это верно.

Интересно. А есть воспроизводимый пример?

Я локализовывал, но вряд ли быстро найду.

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

use warnings FATAL => 'all';
use strict;

# my $a = undef + 42;

# Future doesn't provide stack safety
use Future qw();

sub promise {
  my $n = shift;

  return if $n <= 0;

  return Future->done()
    ->then( sub {
      $n -= 1;
      print "Then. $n left...\n";

      #return promise( $n );
      # This trick doesn't help too
      @_ = ( $n );
      goto &promise;
    } );
}

my $p = promise( 1000000 );

# We get through this even with `use warnings FATAL => 'all';` !!!
print "Here\n";

Ожидание: падение с сообщением о том, что перебрали с рекурсивными вызовами
Реальность: вычисление $p просто заканчвается, но из скрипта не выкидывает и он спокойно доходит до последнего print. При этом даже варнинга никакого нет.

Предупреждение - не пытайтесь это запускать без варнингов: память кончается ооочень быстро.

Т.е. лучше обычные варнинги, без FATAL. С обычными варнингами есть шанс отмониторить эти самые варнинги.