Нашли или выдавили из себя код, который нельзя назвать нормальным,
на который без улыбки не взглянешь?
Не торопитесь его удалять или рефакторить, — запостите его на
говнокод.ру, посмеёмся вместе!
Ну вот подписались вы на событие отсоединения, и вот вам его сообщили. Вы пребываете в полной уверенности что соединение прекратилось, а оно вполне себе работает, сообщает о вашем онлайн присутствии, например. Ну кому как, кому-то может и не критично, но будут люди кому такой ход не понравится 🙂
Это ввод пользователя, там в принципе что угодно может быть, и оно до этого не проверяется (т.е. по задумке автора это публичные API, эта функция не вызывается из авторского кода, а должна вызываться пользователем).
Кроме null могут быть и другие ситуации, когда, например System.useCodepage используется, и в строке будут не Юникоды. Редкостная ситуация, но все же.
Если ввод пользователя, то я с трудом представляю, как можно ввести в поле ввода не пустую строку, а null. К тому же, согласно протоколу, на сервер нужно отправлять не сырой ввод, а как-то декорированный (в XML?), т.е. уже null не получится.
Ошибкой, вероятно, является предоставление этой низкоуровневой функции в публичный API. Но если «публичность» ограничивается одной программой того же авторства, то в этом ничего страшного, автор сам позаботится, чтобы передавать валидные данные.
А почему сразу текстовое поле? А может пользователь посылает sms - откуда вы знаете?
Так автор (т.е. пользователь API) никогда не узнет, что данные не валидны! В этом то и недостаток - т.как если в ответ на невалидные данные выбрасывается исключение - тогда, да, пользователь сообразит, что что-то не так. А если в ответ на невалидные данные происходит какое-то вообще не связаное с ними действие - так откуда ж узнать, что данные были невалидными?
Я не работал с XMPP, но мне кажется сомнительным, что на сервер отсылается просто сырой пользовательский ввод. Как минимум должны быть управляющие команды, а то и в XML всё (на что намекает буковка «хер»).
Не тот сервер... сервер который захватывает и передает дальше ввод с клавиатуры, сорри. В данном случае речь идет про автоматическое тестирование в Гудзоне или похожей системе. Там как бы нет / не будет никаких текстовых полей. SMS - тоже имелось в виду получение ввода от какого-нибудь сервиса, а не набивание текста пользователем. Конечно, это все можно реализовать так, что null не должен будет туда попадать, но для того, чтобы это сделать, нужно ж знать, что это нужно, а для этого нужно найти реализацию этой функции, и увидеть, что она делает совсем не то, что ожидалось. (Нормальный человек посылал бы событие disconnect, когда сокет отключился, а не после ошибки записи в него, которая может быть вызвана другими причинами.
Кроме null могут быть и другие ситуации, когда, например System.useCodepage используется, и в строке будут не Юникоды. Редкостная ситуация, но все же.
Ошибкой, вероятно, является предоставление этой низкоуровневой функции в публичный API. Но если «публичность» ограничивается одной программой того же авторства, то в этом ничего страшного, автор сам позаботится, чтобы передавать валидные данные.
Так автор (т.е. пользователь API) никогда не узнет, что данные не валидны! В этом то и недостаток - т.как если в ответ на невалидные данные выбрасывается исключение - тогда, да, пользователь сообразит, что что-то не так. А если в ответ на невалидные данные происходит какое-то вообще не связаное с ними действие - так откуда ж узнать, что данные были невалидными?
Я не работал с XMPP, но мне кажется сомнительным, что на сервер отсылается просто сырой пользовательский ввод. Как минимум должны быть управляющие команды, а то и в XML всё (на что намекает буковка «хер»).