Что такое режим в коде ошибок

Время на прочтение
9 мин

Количество просмотров 45K

Строгий режим (strict mode) — это важная часть современного JavaScript. Именно этот режим позволяет разработчикам пользоваться более ограниченным, чем стандартный, синтаксисом.

Семантика строгого режима отличается от традиционного нестрогого режима, который иногда называют «грязным» (sloppy mode). В таком режиме синтаксические правила языка не так строги, а когда происходят некоторые ошибки, система никак не оповещает о них пользователя. То есть — ошибки могут быть проигнорированы, а код, в котором они допущены, сможет выполняться дальше. Это способно привести к неожиданным результатам выполнения кода.

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

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

Особенности применения строгого режима

Строгий режим можно применять к отдельным функциям или к целому скрипту. Его нельзя применить только к отдельным инструкциям или к блокам кода, заключённым в фигурные скобки. Для того чтобы использовать строгий режим на уровне целого скрипта, в самое начало файла, до любых других команд, нужно поместить конструкцию "use strict" или 'use strict'.

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

Это приведёт к тому, что код, который не предназначен для выполнения в строгом режиме, окажется в таком состоянии, когда система попытается выполнить его в строгом режиме. Возможно и обратное — код, написанный для строгого режима, попадёт в нестрогий режим. Поэтому лучше всего не смешивать «строгие» и «нестрогие» скрипты.

Как уже было сказано, строгий режим можно применять к отдельным функциям. Для того чтобы это сделать — конструкцию "use strict" или 'use strict' надо поместить в верхнюю часть тела функции, до любых других команд. Строгий режим при таком подходе применяется ко всему, что размещено в теле функции, включая вложенные функции.

Например:

const strictFunction = ()=>{
  'use strict';
  const nestedFunction = ()=>{
    // эта функция тоже использует строгий режим
  }
}

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

Изменения, вводимые в работу JS-кода строгим режимом

Строгий режим влияет и на синтаксис кода, и на то, как код ведёт себя во время выполнения программы. Ошибки в коде преобразуются в исключения. То, что в нестрогом режиме тихо даёт сбой, в строгом вызывает сообщение об ошибке. Это похоже на то, как в нестрогом режиме система реагирует на синтаксические ошибки. В строгом режиме упрощается работа с переменными, жёстко регулируется использование функции eval и объекта arguments, упорядочивается работа с конструкциями, которые могут быть реализованы в будущих версиях языка.

▍Преобразование «тихих» ошибок в исключения

«Тихие» ошибки преобразуются в строгом режиме в исключения. В нестрогом режиме на такие ошибки система явным образом не реагирует. В строгом же режиме наличие таких ошибок приводит к неработоспособности кода.

Так, благодаря этому сложно совершить ошибку случайного объявления глобальной переменной, так как переменные и константы в строгом режиме нельзя объявлять без использования директив var, let или const. В результате создание переменных без этих директив приведёт к неработоспособности программы. Например, попытка выполнения следующего кода приведёт к выдаче исключения ReferenceError:

'use strict';
badVariable = 1;

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

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

Так, например, в строгом режиме нельзя выполнять операции присваивания значений таким сущностям, предназначенным только для чтения, как arguments, NaN или eval.

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

• попытка присваивания значения свойству, предназначенному только для чтения, вроде некоего неперезаписываемого глобального свойства;
• попытка записи значения в свойство, у которого есть лишь геттер;
• попытка записи чего-либо в свойство нерасширяемого объекта.

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

'use strict';

let undefined = 5; 
let Infinity = 5;

let obj = {};
Object.defineProperty(obj, 'foo', { value: 1, writable: false });
obj.foo = 1

let obj2 = { get foo() { return 17; } };
obj2.foo = 2

let fixedObj = {};
Object.preventExtensions(fixedObj);
fixed.bar= 1;

Попытка выполнения подобных фрагментов кода в строгом режиме приведёт к выдаче исключения TypeError. Так, например, undefined и Infinity — это глобальные сущности, значения которых нельзя перезаписывать, а свойство foo объекта obj не поддерживает перезапись. Свойство foo объекта obj2 имеет лишь геттер. Объект fixedObj сделан нерасширяемым с помощью метода Object.preventExtensions.

К выдаче TypeError приведёт и попытка удаления неудаляемого свойства:

'use strict';
delete Array.prototype

Строгий режим запрещает назначать объекту свойства с одинаковыми именами. Как результат — попытка выполнения следующего кода приведёт к возникновению синтаксической ошибки:

'use strict';
let o = { a: 1, a: 2 };

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

В строгом режиме запрещены параметры функций с одинаковыми именами. В результате попытка выполнения следующего кода приведёт к возникновению синтаксической ошибки:

'use strict';
const multiply = (x, x, y) => x*x*y;

В строгом режиме нельзя использовать восьмеричную запись чисел, предваряя число нулём. Этого нет в спецификации, но данная возможность поддерживается браузерами.

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

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

Один из примеров подобного запрета касается инструкции with. Если пользоваться данной инструкцией, то это мешает JS-интерпретатору узнать о том, к какой именно переменной или к какому именно свойству мы обращаемся, так как возможно такое, что сущность с одним и тем же именем имеется и снаружи, и внутри блока инструкции with.

Предположим, есть такой код:

let x = 1;
with (obj) {
  x;
}

Интерпретатор не сможет узнать о том, ссылается ли переменная x, находящаяся внутри блока with, на внешнюю переменную x, или на свойство obj.x объекта obj.

В результате неясно — где именно в памяти будет расположено значение x. Для того чтобы избавиться от подобных неоднозначностей, в строгом режиме использование инструкции with запрещено. Посмотрим, что случится, если попытаться выполнить в строгом режиме следующий код:

'use strict';
let x = 1;
with (obj) {
  x;
}

Результатом этой попытки будет синтаксическая ошибка.

Ещё в строгом режиме запрещено объявлять переменные в коде, переданном методу eval.

Например, в обычном режиме команда вида eval('let x') приведёт к объявлению переменной x. Это позволяет программистам скрывать объявления переменных в строках, что может привести к перезаписи определений тех же переменных, находящихся за пределами eval.

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

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

'use strict';
let x;
delete x;

▍Запрет некорректных синтаксических конструкций

В строгом режиме запрещено неправильное использование eval и arguments. Речь идёт о запрете всяческих манипуляций с ними. Например — это нечто вроде присваивания им новых значений, использование их имён в роли имён переменных, функций, параметров функций.

Вот примеры некорректного использования eval и arguments:

'use strict';
eval = 1;
arguments++;
arguments--;
++eval;
eval--;
let obj = { set p(arguments) { } };
let eval;
try { } catch (arguments) { }
try { } catch (eval) { }
function x(eval) { }
function arguments() { }
let y = function eval() { };
let eval = ()=>{ };
let f = new Function('arguments', "'use strict'; return 1;");

В строгом режиме нельзя создавать псевдонимы для объекта arguments и устанавливать новые значения arguments через эти псевдонимы.

В обычном режиме, если первым параметром функции является a, то установка в коде функции значения a приводит и к изменению значения в arguments[0]. В строгом же режиме в arguments всегда будет содержаться тот список аргументов, с которыми была вызвана функция.

Предположим, имеется следующий код:

const fn = function(a) {
  'use strict';
  a = 2;
  return [a, arguments[0]];
}
console.log(fn(1))

В консоль попадёт [2,1]. Это так из-за того, что запись значения 2 в a не приводит к записи значения 2 в arguments[0].

▍Оптимизации производительности

В строгом режиме не поддерживается свойство arguments.callee. В обычном режиме оно возвращает имя функции-родителя той функции, свойство callee объекта arguments которой мы исследуем.

Поддержка этого свойства мешает оптимизациям, наподобие встраивания функций, так как использование arguments.callee требует доступности ссылки на невстроенную функцию при доступе к этому свойству. В строгом режиме использование arguments.callee приводит к появлению исключения TypeError.

В строгом режиме ключевое слово this не обязано всегда быть объектом. В обычных условиях, если this функции привязывается, с помощью call, apply или bind, к чему-то, что не является объектом, к значению примитивного типа вроде undefined, null, number или boolean, подобное значение должно быть объектом.

Если контекст this меняется на что-то, не являющееся объектом, его место занимает глобальный объект. Например — window. Это означает, что если вызвать функцию, установив её this в некое значение, не являющееся объектом, вместо этого значения в this попадёт ссылка на глобальный объект.

Рассмотрим пример:

'use strict';
function fn() {
  return this;
}
console.log(fn() === undefined);
console.log(fn.call(2) === 2);
console.log(fn.apply(null) === null);
console.log(fn.call(undefined) === undefined);
console.log(fn.bind(true)() === true);

Все команды console.log выведут true, так как в строгом режиме значение this в функции не заменяется автоматически ссылкой на глобальный объект в том случае, если this устанавливается в значение, не являющееся объектом.

▍Изменения, имеющие отношение к безопасности

В строгом режиме нельзя делать общедоступными свойства функции caller и arguments. Дело в том, что caller, например, может дать доступ к функции, вызвавшей функцию, к свойству caller которой мы обращаемся.

В объекте arguments хранятся аргументы, переданные функции при её вызове. Например, если у нас имеется функция fn, это значит, что через fn.caller можно обратиться к функции, вызвавшей данную функцию, а с помощью fn.arguments можно увидеть аргументы, переданные fn при вызове.

Эти возможности представляют собой потенциальную угрозу безопасности. В результате в строгом режиме доступ к этим свойствам запрещён.

function secretFunction() {
  'use strict';
  secretFunction.caller;
  secretFunction.arguments;
}
function restrictedRunner() {
  return secretFunction();
}
restrictedRunner();

В предыдущем примере мы не можем, в строгом режиме, обратиться к secretFunction.caller и secretFunction.arguments. Дело в том, что эти свойства можно использовать для получения стека вызовов функции. Если попытаться запустить этот код — будет выдано исключение TypeError.

В строгом режиме для именования переменных или свойств объектов нельзя использовать идентификаторы, которые могут найти применение в будущих версиях JavaScript. Речь идёт, например, о следующих идентификаторах: implements, interface, let, package, private, protected, public, static и yield.

В ES2015 и в более поздних версиях стандарта эти идентификаторы стали зарезервированными словами. И их нельзя использовать для именования переменных или свойств в строгом режиме.

Итоги

Строгий режим — это стандарт, который существует уже многие годы. Он пользуется чрезвычайно широкой поддержкой браузеров. Проблемы с кодом, выполняемом в строгом режиме, могут возникать лишь у старых браузеров, таких, как Internet Explorer.

У современных браузеров не должно возникать сложностей со строгим режимом JavaScript. В результате можно сказать, что этот режим стоит использовать ради предотвращения «тихих» ошибок и ради повышения безопасности приложений. «Тихие» ошибки преобразуются в исключения, препятствующие выполнению программ, а в плане повышения безопасности можно, например, отметить механизмы строгого режима, ограничивающие eval и предотвращающие доступ к стеку вызовов функций. Кроме того, использование строгого режима облегчает оптимизацию кода JS-движками и заставляет программиста осторожно обращаться с зарезервированными словами, которые могут найти применение в будущих версиях JavaScript.

Уважаемые читатели! Пользуетесь ли вы строгим режимом при написании JS-кода своих проектов?

Добрый день!

Что такое режим отладки или “дебаг” и как его мне его включить на сайте WordPress?

Ответ

Режим отладки больше нужен для проверки изменений, сделанных в коде. Например, Вы что-то изменили или добавили в файл Вашей темы functions.php, а правки оказались с ошибкой. В итоге Вы увидите белый экран без каких-либо объяснений что случилось. Режим отладки или “дебаг” сообщит об ошибке и даже укажет в какой именно строке файла она содержится.

Все действия по включению/отключению режима отладки производятся в основном конфигурационном файле wp-config.php, который находится в корневом каталоге Вашего сайта

WordPress имеет широкие возможности вывода ошибок во время отладки кода. Наиболее грамотным и безопасным считается вывод ошибок не на экран, а запись в файл.

Во-первых, сначала режим нужно задействовать. За это отвечает следующая команда:

define( 'WP_DEBUG', true );

Отметим, что в таком случае все ошибки и предупреждения будут выводиться на экран. Следующие строки запретят визуальный показ ошибок, записывая все сообщения о них в специальный файл, который находится по адресу /wp-content/debug.log.

define( 'WP_DEBUG_LOG', true ); 
define( 'WP_DEBUG_DISPLAY', false );

В итоге, чтобы включить “дебаг”-режим, необходимо в файл wp-config.php добавить следующие строки кода:

// включение режима отладки
define( 'WP_DEBUG', true );
// запись ошибок в файл /wp-content/debug.log
define( 'WP_DEBUG_LOG', true ); 
// запрет вывода ошибок на экран
define( 'WP_DEBUG_DISPLAY', false );

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

Страницы: [1]   Вниз

Автор
Тема: Режимы кодов Ошибок  (Прочитано 2472 раз)

Страницы: [1]   Вверх

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

Определение

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

Баги обнаруживаются чаще всего в момент отладки или бета-тестирования. Реже – после итогового релиза готовой программы. Вот несколько вариантов багов:

1. Появляется сообщение об ошибке, но приложение продолжает функционировать.
2. ПО вылетает или зависает. Никаких предупреждений или предпосылок этому не было. Процедура осуществляется неожиданно для пользователя. Возможен вариант, при котором контент перезапускается самостоятельно и непредсказуемо.
3. Одно из событий, описанных ранее, сопровождается отправкой отчетов разработчикам.

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

История происхождения термина

Баг – слово, которое используется разработчиками в качестве сленга. Оно произошло от слова «bug» – «жук». Точно неизвестно, откуда в программировании и IT возник соответствующий термин. Существуют две теории:

1. 9 сентября 1945 года ученые из Гарварда тестировали очередную вычислительную машину. Она называлась Mark II Aiken Relay Calculator. Устройство начало работать с ошибками. Когда его разобрали, то ученые заметили мотылька, застрявшего между реле. Тогда некая Грейс Хоппер назвала произошедший сбой упомянутым термином.
2. Слово «баг» появилось задолго до появления Mark II. Термин использовался Томасом Эдисоном и указывал на мелкие недочеты и трудности. Во время Второй Мировой войны «bugs» называли проблемы с радарной электроникой.

Второй вариант кажется более реалистичным. Это факт, который подтвержден документально. Со временем научились различать различные типы багов в IT. Далее они будут рассмотрены более подробно.

Как классифицируют

Ошибки работы программ разделяются по разным факторам. Классификация у рядовых пользователей и разработчиков различается. То, что для первых – «просто программа вылетела» или «глючит», для вторых – огромная головная боль. Но существует и общепринятая классификация ошибок. Пример – по критичности:

1. Серьезные неполадки. Это нарушения работоспособности приложения, которые могут приводить к непредвиденным крупным изменениям.
2. Незначительные ошибки в программах. Чаще всего не оказывают серьезного воздействия на функциональность ПО.
3. Showstopper. Критические проблемы в приложении или аппаратном обеспечении. Приводят к выходу программы из строя почти всегда. Для примера можно взять любое клиент-серверное приложение, в котором не получается авторизоваться через логин и пароль.

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

Также существуют различные виды сбоев в плане частоты проявления: постоянные и «разовые». Вторые встречаются редко, чаще – при определенных настройках и действиях со стороны пользователя. Первые появляются независимо от используемой платформы и выполненных клиентом манипуляций.

Иногда может получиться так, что ошибка возникает только на устройстве конкретного пользователя. В данном случае устранение неполадки требует индивидуального подхода. Иногда – полной замены компьютера. Связано это с тем, что никто не будет редактировать исходный код, когда он «глючит» только у одного пользователя.

Виды

Существуют различные типы ошибок в программах в зависимости от типовых условий использования приложений. Пример – сбои, которые возникают при возрастании нагрузки на оперативную память или центральный процессор устройства. Есть баги граничных условий, сбоя идентификаторов, несовместимости с архитектурой процессора (наиболее распространенная проблема на мобильных устройствах).

Разработчики выделяют следующие типы ошибок по уровню сложности:

1. «Борбаг» – «стабильная» неполадка. Она легко обнаруживается на этапе разработки и компилирования. Иногда – во время тестирования наработкой исходной программы.
2. «Гейзенбаг» – баги с поддержкой изменения свойств, включая зависимость от среды, в которой было запущено приложение. Сюда относят периодические неполадки в программах. Они могут исчезать на некоторое время, но через какой-то промежуток вновь дают о себе знать.
3. «Мандельбаг» – непредвиденные ошибки. Обладают энтропийным поведением. Предсказать, к чему они приведут, практически невозможно.
4. «Шрединбаг» – критические неполадки. Приводят к тому, что злоумышленники могут взломать программу. Данный тип ошибок обнаружить достаточно трудно, потому что они никак себя не проявляют.

Также есть классификация «по критичности». Тут всего два варианта – warning («варнинги») и критические весомые сбои. Первые сопровождаются характерными сообщениями и отчетами для разработчиков. Они не представляют серьезной опасности для работоспособности приложения. При компилировании такие сбои легко исправляются. В отдельных случаях компилятор справляется с этой задачей самостоятельно. А вот критические весомые сбои говорят сами за себя. Они приводят к серьезным нарушениям ПО. Исправляются обычно путем проработки логики и значительных изменений программного кода.

Типы багов

Ошибки в программах бывают:

• логическими;
• синтаксическими;
• взаимодействия;
• компиляционные;
• ресурсные;
• арифметические;
• среды выполнения.

Это – основная классификация сбоев в приложениях и операционных системах. Логические, синтаксические и «среды выполнения» встречаются в разработке чаще остальных. На них будет сделан основной акцент.

Ошибки синтаксиса

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

Синтаксические ошибки – ошибки синтаксиса, правил языка. Вот пример в Паскале:

Код написан неверно. Согласно действующим синтаксическим нормам, в Pascal в первой строчке нужно в конце поставить точку с запятой.

Логические

Тут стоит выделить обычные и арифметические типы. Вторые возникают, когда программе при работе необходимо вычислить много переменных, но на каком-то этапе расчетов возникают неполадки или нечто непредвиденное. Пример – получение в результатах «бесконечности».

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

Выше – пример логической ошибки в программе. Тут:

1. Происходит сравнение значения i с 15.
2. На экран выводится сообщение, если I = 15.
3. В заданном цикле i не будет равно 15. Связано это с диапазоном значений – от 1 до 10.

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

Время выполнения

Run-time сбои – это ошибка времени выполнения программы. Встречается даже когда исходный код лишен логических и синтаксических ошибок. Связаны такие неполадки с ходом выполнения программного продукта. Пример – в процессе функционирования ПО был удален файл, считываемый программой. Если игнорировать подобные неполадки, можно столкнуться с аварийным завершением работы контента.

Самый распространенный пример в данной категории – это неожиданное деление на ноль. Предложенный фрагмент кода с точки зрения синтаксиса и логики написан грамотно. Но, если клиент наберет 0, произойдет сбой системы.

Компиляционный тип

Встречается при разработке на языках высокого уровня. Во время преобразований в машинный тип «что-то идет не так». Причиной служат синтаксические ошибки или сбои непосредственно в компиляторе.

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

Ресурсные

Ресурсный тип ошибок – это сбои вроде «переполнение буфера» или «нехватка памяти». Тесно связаны с «железом» устройства. Могут быть вызваны действиями пользователя. Пример – запуск «свежих» игр на стареньких компьютерах.

Исправить ситуацию помогают основательные работы над исходным кодом. А именно – полное переписывание программы или «проблемного» фрагмента.

Взаимодействие

Подразумевается взаимодействие с аппаратным или программным окружением. Пример – ошибка при использовании веб-протоколов. Это приведет к тому, что облачный сервис не будет нормально функционировать. При постоянном возникновении соответствующей неполадки остается один путь – полностью переписывать «проблемный» участок кода, ответственный за соответствующий баг.

Исключения и как избежать багов

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

Исключения бывают:

1. Программными. Они генерируются приложением или ОС.
2. Аппаратными. Создаются процессором. Пример – обращение к невыделенной памяти.

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

P. S. Большой выбор курсов по тестированию есть и в Otus. Присутствуют варианты как для продвинутых, так и для начинающих пользователей.

Как пользоваться кодами ошибок и что такое режим самодиагностики?

Мы уже говорили ранее о том, что бортовой компьютер ВАЗ 2110 штат сильно помогает предупреждать проблемы, возникающие в связи с неправильной работой исполняющих и контрольных систем вашего автомобиля, когда загорается лампочка “Check Engine”. Все это реально, поскольку в чип инсталлирован режим самодиагностики бортовой на компьютер ВАЗ 2112. БК получает информацию от ЭБУ по К-линии и сообщает автомобилисту, что с его железным конем не так.

Это очень важно, поскольку все системы двигателя на ВАЗ-2110 типа инжектор управляются ЭБУ и сбои в его работе и функционировании основных диагностических систем могут привести к выходу из строя всего автомобиля, нерациональному расходу топлива и сильной потери мощности ДВС.

Если у вас имеется компьютер бортовой ВАЗ 2110, вам достаточно просто спросить его, что с автомобилем не так, и ваш “электронный” друг тут же выдаст всю подноготную.

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

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

Если ваш автомобиль комплектуется лишь базовым бортовым компьютером ВАЗ-2110, расположенным под спидометром на приборной панели, то режим самодиагностики в нем запускается при помощи одновременного поворота ключа зажигания и удерживания нажатой кнопки сброса суточного пробега. Сразу после этого перед вами должны начать “плясать” все стрелки на приборной панели.

Нажав два раза на кнопку сброса, мы переключаемся от версии прошивки, собственно, к информации об ошибках Если ваш автомобиль снабжен люксовой комплектацией, где штат бортовой компьютер ВАЗ 2110 установлен рядом с блоком САУО (и АМК 211002), режим самодиагностики там включается еще проще, нажатием кнопки “часы” в режиме отображения времени. Если появляется надпись об ошибке — необходимо просто подключить бортовой компьютер ВАЗ 2110 к диагностическому интерфейсу.