Поясните суть коммикса.
10.05.2016, 12:22
Просто парни не знающие синтаксиса и не знакомые с языками программирования
Скорей всего, речь идет про web-разработчиков, чуваки "поправили" код, который выполняется на сервере и генерит, собственно, ответ сервера. При выполнении такого скрипта возникает ошибка, она перехватывается сервером, и пользователю возвращается HTTP Error 500 Internal server error.
одно другому не противоречит, сервера же не только на интерпретаторах бывают, есть и те, которым нужен билд.
> она перехватывается сервером
Нет. Вебсервер запускает указанный скрипт и ждет от него ответа с характерным заголовком.
Например: Content-type:text/html\n\n
Если скрипт падает до того, как отправил этот заголовок или в процессе своей работы не отправляет его, то по-умолчанию вебсервер выдаст клиенту ошибку 500. Но это, повторюсь, не обязательный исход. Можно в начале скрипта выдать Content-type, а потом скрипт уебется при попытке подключить какой-то модуль - тогда пользователь получит пустую страницу (или, если ошибки пишутся в stdout, то текст ошибки). Или сам скрипт, как это вообще принято делать в приличных проектах, запускает свое основное тело в eval и аккуратно сообщает об ошибке.
Я, короче, это к тому, что не надо перемешивать сущности. Вебсерверу абсолютно насрать на то, что произошло там у скрипта. Получен ответ с правильными заголовками - выдаст его. Не получен или с неправильными - выдаст 500.
Нет. Вебсервер запускает указанный скрипт и ждет от него ответа с характерным заголовком.
Например: Content-type:text/html\n\n
Если скрипт падает до того, как отправил этот заголовок или в процессе своей работы не отправляет его, то по-умолчанию вебсервер выдаст клиенту ошибку 500. Но это, повторюсь, не обязательный исход. Можно в начале скрипта выдать Content-type, а потом скрипт уебется при попытке подключить какой-то модуль - тогда пользователь получит пустую страницу (или, если ошибки пишутся в stdout, то текст ошибки). Или сам скрипт, как это вообще принято делать в приличных проектах, запускает свое основное тело в eval и аккуратно сообщает об ошибке.
Я, короче, это к тому, что не надо перемешивать сущности. Вебсерверу абсолютно насрать на то, что произошло там у скрипта. Получен ответ с правильными заголовками - выдаст его. Не получен или с неправильными - выдаст 500.
а я это к тому, что неправильное название функции ("Add a comment" вместо addComment) вызовет ошибку компиляции или времени выполнения(десктопное приложение). А как "500 Internal server error" оно будет выглядеть только если этот код выполняется на сервере. Хорошо, что мы друг друга поняли. Спасибо, коллега!
Интерпретаторы не особо будут возражать и частично отработают скрипт:
# perl -e 'print "Content-type: text-html\n\n"; Add a Comment'
Content-type: text-html
Can't locate object method "Add" via package "a" (perhaps you forgot to load "a"?) at -e line 1.
Всегда пожалуйста :-)
# perl -e 'print "Content-type: text-html\n\n"; Add a Comment'
Content-type: text-html
Can't locate object method "Add" via package "a" (perhaps you forgot to load "a"?) at -e line 1.
Всегда пожалуйста :-)
ну это примерно как пустили дизайнера в ядерный реактор и он начал там переставлять все по своему усмотрению и согласно фен-шуй.
в программировании некоторые вещи пишутся строго определенным набором символов и другие символы там не допустимы, то есть наименование например функции, переменной, класса, этс не допускает пробелов, т.к. пробел это разделитель лексем.
поэтому пишут либо в camelCase либо StudlyCaps либо с нижними подчеркиваниями, в противном случае компилятор/интерпретатор будет считать совсем не то, что имелось ввиду.
в программировании некоторые вещи пишутся строго определенным набором символов и другие символы там не допустимы, то есть наименование например функции, переменной, класса, этс не допускает пробелов, т.к. пробел это разделитель лексем.
поэтому пишут либо в camelCase либо StudlyCaps либо с нижними подчеркиваниями, в противном случае компилятор/интерпретатор будет считать совсем не то, что имелось ввиду.
Хорошо, что дизайнер долго не протянет в ядерном реакторе.
А еще коммит дизайнера в реактор будет проблематично откатить.
Тогда вопрос, кто пустил дизайнеров на этот реактор?!
На самом деле, даже будучи программистом и зная синтаксис, можно легко что-нибудь сломать, если не знать всех подводных камней в конкретной системе. Не всегда спасает не только авторефакторинг в IDE, но и ручной поиск по коду. Поэтому приходится:
1. Работает - не трогай.
2. Если все же поменял, обязательно тестирование, включая регресс.
Ну и хочется верить, что там всё-таки тестовый стенд. Давать коммитить кому попало в master, да ещё с автобилдом на проде - это уж совсем дно.
1. Работает - не трогай.
2. Если все же поменял, обязательно тестирование, включая регресс.
Ну и хочется верить, что там всё-таки тестовый стенд. Давать коммитить кому попало в master, да ещё с автобилдом на проде - это уж совсем дно.
