Интернет-журнал "Домашняя лаборатория", 2007 №9

Журнал «Домашняя лаборатория»

Этот пример демонстрирует ввод с консоли данных разных типов. Данные, читаемые с консоли методом ReadLine или Read, всегда представляют собой строку, которую затем необходимо преобразовать в нужный тип. Тут-то и вызываются соответствующие методы класса Convert. Естественно, для успеха преобразования строка должна содержать значение в формате, допускающем подобное преобразование. Заметьте, например, что при записи значения числа для выделения дробной части должна использоваться запятая, а не точка; в противном случае возникнет ошибка периода выполнения.

На рис. 4.4 показаны

результаты вывода и ввода данных с консоли при работе этой процедуры.

Рис. 4.4. Вывод на печать результатов теста FromStringTest

Преобразования и класс Convert

Класс Convert, определенный в пространстве имен System, играет важную роль, обеспечивая необходимые преобразования между различными типами. Напомню, что внутри арифметического типа можно использовать более простой, скобочный способ приведения к нужному типу. Но таким способом нельзя привести, например, переменную типа string к типу int, оператор присваивания: uх = (int) s1; приведет к ошибке периода компиляции. Здесь необходим вызов метода ToInt32 класса Convert, как это сделано в последнем примере предыдущего раздела.

Методы класса Convert поддерживают общий способ выполнения преобразований между типами. Класс Convert с одержит 15 статических методов вида Tо <Tуре> (ToBoolean , ToUInt64 ), где туре может принимать значения от Boolean до Uint64 для всех встроенных типов, перечисленных в таблице

3.1. Единственным исключением является тип object, — метода ToObject нет по понятным причинам, поскольку для всех типов существует неявное преобразование к типу object. Среди других методов отмечу общий статический метод ChangeType, позволяющий преобразование объекта к некоторому заданному типу.

Существует возможность преобразования к системному типу DateTime, который хотя и не является встроенным типом языка С#, но допустим в программах, как и любой другой системный тип. Приведу простейший пример работы с этим типом:

// System type: DateTime

System.DateTime dat = Convert.ToDateTime("15.03.2003");

Console.WriteLine("Date = {0}", dat);

Результатом вывода будет строка:

Date = 15.03.2003 0:00:00

Все методы Tо <Tуре> класса Convert перегружены и каждый из них имеет, как правило, более десятка реализаций с аргументами разного типа. Так что фактически эти методы задают все возможные преобразования между всеми встроенными типами языка С#.

Кроме методов, задающих преобразования типов, в классе Convert имеются и другие методы, например, задающие преобразования символов Unicode в однобайтную кодировку ASCII, преобразования значений объектов и другие методы. Подробности можно посмотреть в справочной

системе.

Проверяемые преобразования

Уже упоминалось о том, что при выполнении явных преобразований могут возникать нежелательные явления, например, потеря точности. Я говорил, что вся ответственность за это ложится на программиста, и легче ему от этого не становится. А какую часть этого бремени может взять на себя язык программирования? Что можно предусмотреть для обнаружения ситуаций, когда такие явления все-таки возникают? В языке C# имеются необходимые для этого средства.

Язык C# позволяет создать проверяемый блок, в котором будет осуществляться проверка результата вычисления арифметических выражений. Если результат вычисления значения источника выходит за диапазон возможных значений целевой переменной, то возникнет исключение (говорят также: "будет выброшено исключение") соответствующего типа. Если предусмотрена обработка исключения, то дальнейшее зависит от обработчика исключения. В лучшем случае, программа сможет продолжить корректное выполнение. В худшем, — она остановится и выдаст информацию об ошибке. Заметьте, не произойдет самого опасного — продолжения работы программы с неверными данными.

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

Замечу еще, что и в непроверяемом блоке при работе методов Convert все опасные преобразования проверяются и приводят к выбрасыванию исключений. Приведу пример, демонстрирующий все описанные ситуации:

/// <summary>

/// Демонстрация проверяемых и непроверяемых преобразований.

/// Опасные проверяемые преобразования приводят к исключениям.

/// Опасные непроверяемые преобразования приводят к неверным

/// результатам, что совсем плохо.

/// </summary>

public void CheckUncheckTest

x = —25 ^2;

WhoIsWho ("x", x);

b= 2 55;

WhoIsWho("b",b);

// Проверяемые опасные преобразования.

// Возникают исключения, перехватываемые catch-блоком,

checked

{

try

{

b += 1;

}

catch (Exception e)

{

Console.WriteLine("Переполнение при вычислении b");

Console.WriteLine(e);

}

try

{

b = (byte)x;

}

catch (Exception e)

{

Console.WriteLine("Переполнение при преобразовании к byte");

Console.WriteLine(e);

}

// непроверяемые опасные преобразования

unchecked

{

try

{

b +=1;

WhoIsWho ("b", b);

b = (byte)x;

WhoIsWho ("b", b);

ux= (uint)x;

WhoIsWho ("ux", ux);

Console.WriteLine("Исключений нет, но результаты не верны!");

}

catch (Exception е)

{

Console.WriteLine("Этот текст не должен появляться");

Console.WriteLine (е);

}

// автоматическая проверка преобразований в Convert

// исключения возникают, несмотря на unchecked

try

}