Олег Правдин

bittorrent.

Будут, потому что они смотрят на заголовки внутри, а не на название файла.

Только формат файла от этого и не поменяется, это будет jpg который обозван как png.

Используйте систему слотов:

В компоненте таблицы:

...
<tr v-for="row in rows">
  <td v-for="header in headers">
    <slot :name="`cel_${header.key}`" :row="row"> {{ row[header.key] }} </slot>
  </td>
</tr>
...

Использование компонента таблицы:

...
<table-component :rows="users" :headers="headers">
  <template slot="cel_full_name" slot-scope="props">
    <router-link :to="`/user/${props.row.id}`">{{ props.row.full_name }}</router-link>
  </template>
</table-component>
...

Очень хороший вопрос и тема, в которой самое чудовищное количество самых дремучих северий на единицу кода.

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

Я понимаю, что это звучит богохульством для среднего пользователя похапе, но в реальности программы пишутся совсем по-другому.

Пример: В обоих приведенных выше случаях мы имеем масло масляное: попытка подменить пхп в выборосе ошибки. Вопрос - зачем? Если файл не найден, то РНР сам прекрасно сообщит нам об ошибке, причем в подробностях, и скажет в чем конкретно заключается проблема. А по строчке "file not found" иди гадай - путь ли кривой или в имени файла опечатка, или вообще пустоту передали.

Любые проверки надо делать только тогда, когда есть осмысленный сценарий их обработки.

И обсуждать выше приведенные примеры имеет смысл только если автор вопроса предоставит такой сценарий. тупое error: file not found таким сценарием не является. Так что в общем случае оставляем код в покое и не устраиваем никакого карго культа из перехвата ошибок.

Если чисто выбирать между двумя действиями (проверка и чтение) и одним (сразу читаем, потом ловим исключение),

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

Но повторюсь, если нет никакого осмысленного сценария обработки ошибки, то ловить её не надо.

В таком примере, как вы привели, if() проверяет только условие существования файла или директории. А try-catch обработает бОльшее число ситуаций: если это не файл, а директория, если права не позволяют читать, если устройство гакнулось и не прочиталось.


По замыслу if отличается тем, что проверяет предусмотренные варианты, а исключения кидаются в непредусмотренных. Все бросаемые исключения надо документировать, чтобы их кто-то где-то, в итоге, поймал.

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

Внешние материалы по теме:

1. Пост по теме (на англ.)
   
2. скорость выполнения с исключениями и без (без быстрее)
   
3. Exception patterns, в частности:
   
   • Use Exceptions Instead Of Error Values
     
   • Don't Use Exceptions For Flow Control
     
   • Avoid Exceptions Whenever Possible
     
   • Code Without Exceptions
   
   
   

Что я делаю не так?

Нужно добавить <link rel="preload" />, а не заменить ими ваши скрипты.

Для этого используется TLS. Это спец-протокол, который решает все вопросы, которые вы хотите решить. Там есть возможность шифрования, взаимной аутентификации как клиента, так и сервера и всё такое. Минусы -- вычислительно сложно. Т. е. на слабых микроконтроллерах процесс установления TLS-сессии может занимать время, плюс расход батарей. Плюсы -- уже есть готовые либы под множество платформ/архитектур, которые можно использовать, чтобы не изобретать велосипеды и не писать своё.

Гарантия от replay attack достигается тем, что для передачи команды сторонам нужно аутентифицироваться, т. е. это всегда двусторонний обмен. Технически сначала стороны обмениваются сертификатами, проверяют их, затем на основании алгоритма Диффи-Хэллмана формируют симметричный ключ шифрования, который будет использоваться для шифрования потока данных. В общем случае, в каждой сессии этот ключ будет разным. Есть механизмы кэширования и сохранения стейта, для ускорения установления TLS-сессии (допустим, на случай если клиент недавно уже подключался) -- это нужно, чтобы увеличить скорость согласования TLS-соединения), но это всё опционально и отключабельно.

Внутрь TLS можно засунуть что угодно -- кастомный бинарный протокол на базе TCP/IP или REST API на базе HTTP -- без разницы.

10 лет это 3 класс

Отстаньте лучше от ребёнка. Ему всего лишь 10 лет - какое программирование? Пусть он сначала насладится детством. А уже после - сам начнёт ковыряться в том, что ему понравится