(PHP 4 >= 4.0.1, PHP 5, PHP 7)
set_error_handler — Задает определенный пользователем обработчик ошибок
Описание
Задает пользовательскую функцию ( error_handler ), как обработчик ошибок в скрипте.
Эта функция используется для определения собственного обработчика ошибок времени выполнения скрипта. Например, если требуется очистить данные/файлы, когда произошла критическая ошибка, или если нужно переключить тип ошибки, исходя из каких-то условий (используя функцию trigger_error() ).
Также важно помнить, что на совести обработчика лежит вызов функции die() в случае необходимости. Если происходит возврат их обработчика ошибок, управление передается следующему выражению, стоящему за тем, что вызвало ошибку.
Если ошибки возникают до запуска скрипта (например, пока файл загружается), пользовательский обработчик не будет вызываться, если на этот момент он еще не зарегистрирован.
Список параметров
Возвращаемые значения
Список изменений
Примеры
Пример #1 Обработка ошибок с помощью функций set_error_handler() и trigger_error()
Пример ниже демонстрирует обработку внутренних исключений путем вызова ошибок разных типов и их обработки пользовательской функцией:
/* Не запускаем внутренний обработчик ошибок PHP */
return true ;
>
// переключаемся на пользовательский обработчик
$old_error_handler = set_error_handler ( «myErrorHandler» );
Результатом выполнения данного примера будет что-то подобное:
Смотрите также
Обработка ошибок в PHP
Обработка ошибок с помощью trigger_error() и set_error_handler()
PHP предоставляет прекрасную возможность контролировать возникающие ошибки. Здесь мы поговорим о том, как обработать ошибку — сообщить (или не сообщить) о происшествии пользователю, в случае необходимости — сообщить администратору с помощью электронной почты, записать информацию о происшествии в log-файл.
Итак, для начала давайте определимся, что такое ошибки в PHP.
PHP поддерживает следующие уровни ошибок:
E_ERROR
E_WARNING
E_PARSE
E_NOTICE
E_CORE_ERROR
E_CORE_WARNING
E_COMPILE_ERROR
E_COMPILE_WARNING
E_USER_ERROR
E_USER_WARNING
E_USER_NOTICE
E_ALL
E_STRICT
На самом деле — это просто константы, которые используются для определения уровня обработки ошибок, построения бит-маски. Константы имеют «говорящие» имена. Глядя на константу — мы можем сказать, что ошибка уровня E_PARSE возникает в случае синтаксической ошибки, E_NOTICE — это напоминание программисту о нарушении «хорошего стиля» программирования на PHP.
Когда соединение с базой данных MySQL (или другой) завершается неудачей — интерпретатор PHP сообщает об ошибке уровня E_WARNING
php_flag display_errors on
php_value error_reporting «E_ALL &
Это означает, что сообщения об ошибках будут показываться, причем всех уровней, кроме E_NOTICE
Когда программист допускает синтаксическую ошибку — интерпретатор PHP сообщает об ошибке уровня E_PARSE
Parse error: parse error, unexpected ‘(‘, expecting T_STRING in /home/mysite/index.php on line 150
Но самые интересные для нас уровни ошибок — E_USER_ERROR и E_USER_WARNING. Как становится понятно из названия — это уровни ошибок, которые может устанавливать пользователь. Для этого существует функция trigger_error() — с её помощью, Вы можете сообщать пользователю о происшествии так, как это делает PHP.
Как известно из руководства по PHP — функция trigger_error() принимает два параметра.
void trigger_error ( string error_msg [, int error_type])
Первый параметр — текстовое сообщение об ошибке, например «файл не найден». Второй параметр — определяет уровень ошибки. Функция trigger_error() работает только с семейством ошибок E_USER — это значит, что вы можете установить ошибку уровня E_USER_ERROR, E_USER_WARNING, E_USER_NOTICE и не можете установить ошибку уровня E_WARNING. Второй параметр является не обязательным, и по умолчанию принимает значение E_USER_NOTICE.
Допустим, наши данные для ленты новостей хранятся в файле news.txt, и если файл не найден — необходимо сообщить об ошибке. Текст программы будет выглядеть примерно так:
if (!file_exists(‘/home/mysite/news.txt’)) <
trigger_error(‘News file not found’);
>
В результате интерпретатор PHP сообщит об ошибке уровня E_USER_NOTICE
php_value log_errors «1»
php_value log_errors_max_len «1024»
php_value error_log «/home/mysite/my.log»
То в файл /home/mysite/my.log автоматически будет добавлена запись о происшествии.
[23-Mar-2004 13:52:03] PHP Notice: News file not found in /home/mysite/index.php on line 47
Далее, с помощью функции set_error_handler() мы можем установить свой собственный обработчик ошибок возникающих во время выполнения PHP скрипта.
Как известно из мануала — в PHP 4 функция принимает один единственный строковый параметр — имя функции, которая будет выполняться каждый раз, когда происходит ошибка. PHP 5 даёт возможность установить ещё один параметр — тип ошибок которые будут обрабатываться с помощью нашего обработчика. Функция возвращает строку — имя функции обработчика, который был установлен до этого момента.
string set_error_handler ( callback error_handler [, int error_types])
set_error_handler («my_error_handler»);
Пользовательская функция, которая будет обрабатывать ошибки, может принимать следующие входные параметры:
— код уровня ошибки
— строковая интерпретация ошибки
— имя файла, в котором произошла ошибка
— строка, в которой произошла ошибка
Следует так же заметить, что эта функция не может обрабатывать ошибки уровней E_ERROR, E_PARSE, E_CORE_ERROR, E_CORE_WARNING, E_COMPILE_ERROR, E_COMPILE_WARNING
Это связанно с тем, что ошибки перечисленных уровней происходят до того, как интерпретатор получает информацию о пользовательском обработчике ошибок.
Итак, объявляем нашу функцию
Замечание: каждый более-менее объемный скрипт обычно разделяется на несколько файлов для удобства работы с ним. Как организовывать модульность программы — тема отдельно разговора. Сейчас же, я хочу лишь посоветовать выделять общие настройки в отдельный файл, который будет подключаться в начале программы с помощью инструкции include, либо с помощью директивы auto_prepend_file. В этот файл можно поместит и наш обработчик. Установка обработчика ошибок должна осуществится как можно ближе к началу программы, желательно в самом начале.
Для того чтобы убедится что это действительно работает — создадим новый PHP файл, и попробуем запустить его
Содержимое файла myerrortest.php
Результат обработки данного файла будет таким:
Произошла ошибка News file not found (1024)
/home/mysite/myerrortest.php (12)
Теперь у нас есть функция, которая получает данные обо всех происходящих ошибках. Подумаем, как мы можем это использовать.
Будем обрабатывать ошибки уровней
E_ERROR
E_WARNING
E_NOTICE
E_USER_ERROR
E_USER_NOTICE
Первые три ошибки в хорошей законченной программе не должны происходить вообще, поэтому о них мы будем только сообщать пользователю выводом текста ошибки на экран. Так можно работать, пока скрипт в состоянии разработки, затем сообщения о них можно либо отключить, либо записывать в log-файл.
Что касается остальных двух — как Вы уже догадались — они могу там пригодиться. Мы сами будем вызывать ошибки этих уровней в случае необходимости. Допустим — ошибки уровня E_USER_ERROR — будем вызывать в случае, когда сообщение об ошибке должно попасть в log-файл и быть отправлено на e-mail администратору (например — ошибка при выполнении SQL запроса, или отсутствии парв доступа к необходимому файлу). Ошибки уровня E_USER_NOTICE будут вызываться при возникновении «лёгких» ошибок (например — пользователь некорректно заполнил форму, или запросил из базы несуществующую запись).
Теперь наша функция обработки ошибок будет выглядеть примерно так:
Для того чтобы пример заработал — просто скопируйте в PHP-файл три предыдущих блока кода. Не забудьте установить права доступа на log-файл 777 для того чтобы скрипт мог с ним работать, прописать правильные пути и указать свой e-mail. Вы можете включить режим отладки установкой переменной DEBUG в 1.
Это довольно простой пример, тему можно развивать.
set_error_handler
(PHP 4 >= 4.0.1, PHP 5, PHP 7, PHP 8)
set_error_handler — Задаёт пользовательский обработчик ошибок
Описание
Задаёт пользовательскую функцию ( callback ), как обработчик ошибок в скрипте.
Эта функция используется для определения собственного обработчика ошибок времени выполнения скрипта. Например, если требуется очистить данные/файлы, когда произошла критическая ошибка, или если нужно переключить тип ошибки, исходя из каких-то условий (используя функцию trigger_error() ).
Также важно помнить, что на совести обработчика лежит вызов функции die() в случае необходимости. Если происходит возврат из обработчика ошибок, управление передаётся следующему выражению, стоящему за тем, что вызвало ошибку.
Если ошибки возникают до запуска скрипта (например, пока файл загружается), пользовательский обработчик не будет вызываться, если на этот момент он ещё не зарегистрирован.
Список параметров
Этот параметр объявлен УСТАРЕВШИМ начиная с PHP 7.2.0 и был УДАЛЁН в PHP 8.0.0. Если в вашей функции этот параметр используется и для него не задано значение по умолчанию, то при вызове функции обработчика будет выдана ошибка «too few arguments».
Возвращаемые значения
Список изменений
Примеры
Пример #1 Обработка ошибок с помощью функций set_error_handler() и trigger_error()
Пример ниже демонстрирует обработку внутренних исключений путём вызова ошибок разных типов и их обработки пользовательской функцией:
/* Не запускаем внутренний обработчик ошибок PHP */
return true ;
>
// переключаемся на пользовательский обработчик
$old_error_handler = set_error_handler ( «myErrorHandler» );
Результатом выполнения данного примера будет что-то подобное:
Смотрите также
User Contributed Notes 40 notes
By this function alone you can not catch fatal errors, there is a simple work around. Below is part of my error.php file which handles errors and exceptions in the application. Before someone complains I’ll add that I do not care that I am using globals, this file is part of my mini framework and without the ‘config’ variable the application would crash anyways.
Exception Occured:
class WarningException extends ErrorException <>
class ParseException extends ErrorException <>
class NoticeException extends ErrorException <>
class CoreErrorException extends ErrorException <>
class CoreWarningException extends ErrorException <>
class CompileErrorException extends ErrorException <>
class CompileWarningException extends ErrorException <>
class UserErrorException extends ErrorException <>
class UserWarningException extends ErrorException <>
class UserNoticeException extends ErrorException <>
class StrictException extends ErrorException <>
class RecoverableErrorException extends ErrorException <>
class DeprecatedException extends ErrorException <>
class UserDeprecatedException extends ErrorException <>
//calling custom error handler
set_error_handler ( «handleError» );
Be careful when using the return value to this function. Because it returns the old handler, you may be tempted to do something like:
So always restore the old error handler using that function instead:
function do_something ()
<
set_error_handler ( “my_error_handler” );
// Do something you want handled by my_error_handler
restore_error_handler ();
>
?>
(‘Course, there are ways to create your handler to handle even this situation, but it’s probably best left this way for general purposes.)
This might be handy if you don’t want your clients to see the errors, and you do want to be one step ahead of them.
It emails you the errors even if it’s a parse error.
set_error_handler() doesn’t work for what I wanted.
Keep in mind that, when attempting to set a statically-defined error handler on a namespaced class in PHP >= 5.3, you need to use the class namespace:
This may be of help to someone, who is/was looking for a way to get a backtrace of fatal errors such as maximum memory allocation issues, which can not be handled with user-defined functions, to pin-point the problem:
On a server hosting many sites that share common PHP includes, I set in one spot:
And that at least helped me tremendously to then further pin-point where the problem is, as opposed to before just seeing the out of memory and not knowing which site/page it was on (as the PHP error only contains the very latest PHP code where it ran out of memory, which usually is just a shared included file, not the actual page).
I have realized that a few people here mentioned that you cannot capture parse errors (type 4, E_PARSE). This is not true. Here is how I do. I hope this helps someone.
1) Create a «auto_prepend.php» file in the web root and add this:
* make sure you change the email address and the path to the file.
We needed to use an error handler to handle SQL errors while passing the query along so the query is also logged and this is what we came up with, its kind of an ugly bridge but it works 100%
case E_USER_WARNING :
case E_USER_NOTICE :
>
/* Don’t execute PHP internal error handler */
return true ;
>
// function to test the error handling
This actually works to catch Fatal errors.
function error () <
// dont let PHP know of our error handler yet
>
«The following error types cannot be handled with a user defined function: E_ERROR, E_PARSE, E_CORE_ERROR, E_CORE_WARNING, E_COMPILE_ERROR, E_COMPILE_WARNING, and most of E_STRICT raised in the file where set_error_handler() is called.»
This is not exactly true. set_error_handler() can’t handle them, but ob_start() can handle at least E_ERROR.
i made an error handler that print also the backtrace and that can die on some errors. It can be useful if you want to die on every error you find.
( E_ALL ); // will report all errors
set_error_handler ( ‘my_error_handler’ );
error_fatal ( E_ALL ^ E_NOTICE ); // will die on any error except E_NOTICE
?>
// error_get_last() is now in a well known state:
// Undefined variable: undef_var
To honor the value of PHP’s error_reporting() function, use:
Two notes on using set_error_handler() on behaviour that I noticed when migrating an application from php 4.2.1 to php 4.3.9 (I do not yet have php 5.0 available, this might not apply there!).
1. setting the system error handler
If you want to set the standard php error handler again, after having set your own error handler, this works in php 4.2.1 by passing in an empty string:
$last_handler = set_error_handler ( «my_handler» );
// restore standard error handler
?>
The very same code now raises an error in php 4.3.9:
set_error_handler() expects argument 1, », to be a valid callback
(Since the return value of the first call to set_error_handler() is still the empty string «», I don’t see how this can be done any more. I don’t really need this, because I use my own handlers as shown below, but it might be good to be aware of this.)
2. setting your own ‘second level’ handler
If you have set your own error handler, and want to replace it by another one (other than the standard php error handler) while it is being executed, note that the return value of set_error_handler when used INSIDE the error handler is «» instead of the name of the previous handler! This is not too surprising, because during execution of your self defined error handler, php replaces it with the standard php error handler to avoid infinite loops in case of problems inside the handler. This is only interesting if you want nested handlers as I do. Background of my design:
1st level handler: log into DB
2nd level handler: log into flat file (if log into DB fails)
3rd level handler: print to stdout (if log into flat file fails) (this is the sytem handler, finally).
// but we want to have a fallback handler different
// to the standard error handler
$last_handler = set_error_handler ( «my_fallback_handler» );
$last_handler = set_error_handler ( «my_handler» );
$last_handler = set_error_handler ( «my_handler» );
For anyone interested in the actual translated error codes and their meanings:
1 E_ERROR (integer) Fatal run-time errors. These indicate errors that can not be recovered from, such as a memory allocation problem. Execution of the script is halted.
2 E_WARNING (integer) Run-time warnings (non-fatal errors). Execution of the script is not halted.
4 E_PARSE (integer) Compile-time parse errors. Parse errors should only be generated by the parser.
8 E_NOTICE (integer) Run-time notices. Indicate that the script encountered something that could indicate an error, but could also happen in the normal course of running a script.
16 E_CORE_ERROR (integer) Fatal errors that occur during PHP’s initial startup. This is like an E_ERROR, except it is generated by the core of PHP.
32 E_CORE_WARNING (integer) Warnings (non-fatal errors) that occur during PHP’s initial startup. This is like an E_WARNING, except it is generated by the core of PHP.
64 E_COMPILE_ERROR (integer) Fatal compile-time errors. This is like an E_ERROR, except it is generated by the Zend Scripting Engine.
128 E_COMPILE_WARNING (integer) Compile-time warnings (non-fatal errors). This is like an E_WARNING, except it is generated by the Zend Scripting Engine.
256 E_USER_ERROR (integer) User-generated error message. This is like an E_ERROR, except it is generated in PHP code by using the PHP function trigger_error().
512 E_USER_WARNING (integer) User-generated warning message. This is like an E_WARNING, except it is generated in PHP code by using the PHP function trigger_error().
1024 E_USER_NOTICE (integer) User-generated notice message. This is like an E_NOTICE, except it is generated in PHP code by using the PHP function trigger_error().
2048 E_STRICT (integer) Enable to have PHP suggest changes to your code which will ensure the best interoperability and forward compatibility of your code. Since PHP 5 but not included in E_ALL until PHP 5.4.0
4096 E_RECOVERABLE_ERROR (integer) Catchable fatal error. It indicates that a probably dangerous error occurred, but did not leave the Engine in an unstable state. If the error is not caught by a user defined handle (see also set_error_handler()), the application aborts as it was an E_ERROR. Since PHP 5.2.0
8192 E_DEPRECATED (integer) Run-time notices. Enable this to receive warnings about code that will not work in future versions. Since PHP 5.3.0
16384 E_USER_DEPRECATED (integer) User-generated warning message. This is like an E_DEPRECATED, except it is generated in PHP code by using the PHP function trigger_error(). Since PHP 5.3.0
32767 E_ALL (integer) All errors and warnings, as supported, except of level E_STRICT prior to PHP 5.4.0. 32767 in PHP 5.4.x, 30719 in PHP 5.3.x, 6143 in PHP 5.2.x, 2047 previously
How to handle fatal errors in php 5.2:
«errcontext will contain an array of every variable that existed in the scope the error was triggered in. User error handler must not modify error context.»
In other words, the language in the manual is misleading, because errcontext is NOT a copy of the variables that existed when the error WAS triggered, but rather is a reference to the *existing LIVE variables* in the calling script.
The significance of that is that if you modify errcontext, you will be modifying those other variables, not just for the life of your error handling function, but for the life of the calling script as well.
This should be made clearer in the manual, starting by marking errhandler with an ampersand (&) for passage by reference in the «Parameters» section above, like so:
Полный список
— разбираемся, что такое Handler и зачем он нужен
Для полного понимания урока желательно иметь представление о потоках (threads) в Java.
Так просто ведь и не объяснишь, что такое Handler. Можете попробовать почитать официальное описание, но там достаточно нетривиально и мало написано. Я попробую здесь в двух словах рассказать.
В Android к потоку (thread) может быть привязана очередь сообщений. Мы можем помещать туда сообщения, а система будет за очередью следить и отправлять сообщения на обработку. При этом мы можем указать, чтобы сообщение ушло на обработку не сразу, а спустя определенное кол-во времени.
Handler дает нам две интересные и полезные возможности:
1) реализовать отложенное по времени выполнение кода
2) выполнение кода не в своем потоке
В этом уроке сделаем небольшое приложение. Оно будет эмулировать какое-либо долгое действие, например закачку файлов и в TextView выводить кол-во закачанных файлов. С помощью этого примера мы увидим, зачем может быть нужен Handler.
Project name: P0801_Handler
Build Target: Android 2.3.3
Application name: Handler
Package name: ru.startandroid.develop.p0801handler
Create Activity: MainActivity
ProgressBar у нас будет крутиться всегда. Позже станет понятно, зачем. TextView – для вывода информации о закачке файлов. Кнопка Start будет стартовать закачку. Кнопка Test будет просто выводить в лог слово test.
В обработчике кнопки Start мы организуем цикл для закачки файлов. В каждой итерации цикла выполняем метод downloadFile (который эмулирует закачку файла), обновляем TextView и пишем в лог информацию о том, что кол-во закачанных файлов изменилось. Итого у нас должны закачаться 10 файлов и после закачки каждого из них лог и экран должны показывать, сколько файлов уже закачано.
По нажатию кнопки Test – просто выводим в лог сообщение.
downloadFile – эмулирует закачку файла, это просто пауза в одну секунду.
Все сохраним и запустим приложение.
Мы видим, что ProgressBar крутится. Понажимаем на кнопку Test, в логах появляется test. Все в порядке, приложение отзывается на наши действия.
Теперь расположите AVD на экране монитора так, чтобы он не перекрывал вкладку логов в Eclipse (LogCat). Нам надо будет видеть их одновременно.
Если мы нажмем кнопку Start, то мы должны наблюдать, как обновляется TextView и пишется лог после закачки очередного файла. Но на деле будет немного не так. Наше приложение просто «зависнет» и перестанет реагировать на нажатия. Остановится ProgressBar, не будет обновляться TextView, и не будет нажиматься кнопка Test. Т.е. UI (экран) для нас станет недоступным. И только по логам будет понятно, что приложение на самом деле работает и файлы закачиваются. Нажмите Start и убедитесь.
Экран «висит», а логи идут. Как только все 10 файлов будут закачаны, приложение оживет и снова станет реагировать на ваши нажатия.
А все почему? Потому что работа экрана обеспечивается основным потоком приложения. А мы заняли весь этот основной поток под свои нужды. В нашем случае, как будто под закачку файлов. И как только мы закончили закачивать файлы – поток освободился, и экран стал снова обновляться и реагировать на нажатия.
Т.е. мы просто помещаем весь цикл в новый поток и запускаем его. Теперь закачка файлов пойдет в этом новом потоке. А основной поток будет не занят и сможет без проблем прорисовывать экран и реагировать на нажатия. А значит, мы будем видеть изменение TextView после каждого закачанного файла и крутящийся ProgressBar. И, вообще, сможем полноценно взаимодействовать с приложением. Казалось бы, вот оно счастье 🙂
Все сохраним и запустим приложение. Жмем Start.
Приложение вылетело с ошибкой. Смотрим лог ошибок в LogCat. Там есть строки:
android.view.ViewRoot$CalledFromWrongThreadException: Only the original thread that created a view hierarchy can touch its views.
Смотрим, что за код у нас в MainActivity.java в 37-й строке:
При попытке выполнить этот код (не в основном потоке) мы получили ошибку «Only the original thread that created a view hierarchy can touch its views». Если по-русски, то «Только оригинальный поток, создавший view-компоненты, может взаимодействовать с ними». Т.е. работа с view-компонентами доступна только из основного потока. А новые потоки, которые мы создаем, не имеют доступа к элементам экрана.
Т.е. с одной стороны нельзя загружать основной поток тяжелыми задачами, чтобы не «вешался» экран. С другой стороны – новые потоки, созданные для выполнения тяжелых задач, не имеют доступа к экрану, и мы не сможем из них показать пользователю, что наша тяжелая задача как-то движется.
Тут нам поможет Handler. План такой:
— мы создаем в основном потоке Handler
— в потоке закачки файлов обращаемся к Handler и с его помощью помещаем в очередь сообщение для него же самого
— система берет это сообщение, видит, что адресат – Handler, и отправляет сообщение на обработку в Handler
— Handler, получив сообщение, обновит TextView
Чем это отличается от нашей предыдущей попытки обновить TextView из другого потока? Тем, что Handler был создан в основном потоке, и обрабатывать поступающие ему сообщения он будет в основном потоке, а значит, будет иметь доступ к экранным компонентам и сможет поменять текст в TextView. Получить доступ к Handler из какого-либо другого потока мы сможем без проблем, т.к. основной поток монополизирует только доступ к UI. А элементы классов (в нашем случае это Handler в MainActivity.java) доступны в любых потоках. Таким образом Handler выступит в качестве «моста» между потоками.
Перепишем метод onCreate:
Метод onclick перепишем так:
Мы деактивируем кнопку Start перед запуском закачки файлов. Это просто защита, чтобы нельзя было запустить несколько закачек одновременно. А в процессе закачки, после каждого закачанного файла, отправляем (sendEmptyMessage) для Handler сообщение с кол-вом уже закачанных файлов. Handler это сообщение примет, извлечет из него кол-во файлов и обновит TextView.
Все сохраняем и запускаем приложение. Жмем кнопку Start.
Кнопка Start стала неактивной, т.к. мы ее сами выключили. А TextView обновляется, ProgressBar крутится и кнопка Test нажимается. Т.е. и закачка файлов идет, и приложение продолжает работать без проблем, отображая статус закачки.
Когда все файлы закачаются, кнопка Start снова станет активной.
Подытожим все вышесказанное.
1) Сначала мы попытались грузить приложение тяжелой задачей в основном потоке. Это привело к тому, что мы потеряли экран – он перестал обновляться и отвечать на нажатия. Случилось это потому, что за экран отвечает основной поток приложения, а он был сильно загружен.
2) Мы создали отдельный поток и выполнили весь тяжелый код там. И это бы сработало, но нам надо было обновлять экран в процессе работы. А из не основного потока доступа к экрану нет. Экран доступен только из основного потока.
3) Мы создали Handler в основном потоке. А из нового потока отправляли для Handler сообщения, чтобы он нам обновлял экран. В итоге Handler помог нам обновлять экран не из основного потока.
Достаточно сложный урок получился. Наверняка, мало, что понятно. Не волнуйтесь, в этом уроке я просто показал, в какой ситуации Handler может быть полезен. А методы работы с ним мы рассмотрим подробно в следующих уроках.
Eclipse может подчеркивать Handler желтым цветом и ругаться примерно такими словами: «This Handler class should be static or leaks might occur«. Тем самым он сообщает нам, что наш код немного плох и может вызвать утечку памяти. Тут он прав абсолютно, но я в своих уроках все-таки буду придерживаться этой схемы, чтобы не усложнять.
На следующем уроке:
— посылаем простейшее сообщение для Handler
Присоединяйтесь к нам в Telegram:
— в канале StartAndroid публикуются ссылки на новые статьи с сайта startandroid.ru и интересные материалы с хабра, medium.com и т.п.
— в чатах решаем возникающие вопросы и проблемы по различным темам: Android, Kotlin, RxJava, Dagger, Тестирование
— ну и если просто хочется поговорить с коллегами по разработке, то есть чат Флудильня
— новый чат Performance для обсуждения проблем производительности и для ваших пожеланий по содержанию курса по этой теме
