Обработка ошибок в OleDB

"Открывать и закрывать соединение при каждом запросе нет необходимости и скорее всего проблематично с точки зрения производительности."

Насколько я знаю, механика Ole DB автоматически использует пул соединений. Операция закрытия соединения физически не освобождает ресурсы, связанные с ним, поэтому можно открывать и закрывать до посинения без потерь производительности. Хотя, надо конечно не закрывать в явном виде а просто использовать using.

Message 993

Выводить на экран осмысленное сообщение об ошибке можно, и нужно. При использовании программы пользователь далеко не всегда будет обращаться напрямую в техподдержку разработчика, в первую очередь - к системному администратору. И для него будет полезно будет видеть технические данные ошибки. (Сообщение типа "OleDbException: Не удалось получить доступ к файлу" несет больше информации чем "Что-то поломалось"). Просто надо сбалансировать компактность сообщения и полноту информации. Для меня, правильный шаблон обработки исключения должен выглядеть как-то так

try
{
	/* ... */
}
catch(Exception ex)
{
	MessageBox.Show(ex.GetType().ToString()+": "+ex.Message+" в "+ex.Source, "Ошибка");
	ErrorLog.WriteLine(DateTime.Now.ToString()+". При выполнении операции (...) произошла ошибка:");
	ErrorLog.WriteLine(ex.ToString());	
}

Если же принцип разработки "лишь бы работало", используется технология WinForms или ASP.NET, и приложение однопоточное, исключения лучше вообще не обрабатывать. WinForms при необрабатываемом исключении сама выводит сообщение с подробной информацией на экран. В случае ASP.NET пользователю выводится стандартное бессмысленное сообщение, а подробную информацию об ошибке IIS складывает в системный журнал. К сожалению, это не работает в других типах приложений:

WPF - при необрабатываемом исключении программа падает с бессмысленным системным сообщением об ошибке.

Служба - ошибка будет проигнорирована без какой-либо возможности узнать что произошло

Многопоточное приложение WinForms - ошибка в фоновом потоке будет также молча проигнорирована

В общем, обработка ошибок всегда - по ситуации.

Message 990

"Поясните (что бы не искать) "ErrorLog.WriteLine(DateTime.Now.ToString()+...". При вы" - куда пишет?"

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

"И еще SQLException - аналогично? Мне кажется, что там есть отличия: сначала SQL-сервер выдает ошибки, а топом только в программу попадает."

При возникновении ошибки в SQL Servere действительно сналчала генерируется внутреннее исключение, которое можно обработать из кода Transact SQL. Но обычно это не нужно, если только не используется сложная логика транзакций. Так что обработка исключения SQL Server не отличается от обработки любых других исключений (кроме того факта, что параметр Message этих исключений более информативен чем других, а в дополнительных данных исключения даже храниться идентификатор соединения и ссылка на страницу справки на сайте microsoft).

Message 988

"Скажем, в примере выше как Message так и Souce могут быть пустыми строками что выведет какую то абракадабру с точки зрения пользователя. Да и сам по себе вывод MessageBox неудачен"

Я привел только как пример, передать суть алгоритма. В реальном проекте надо конечно проверить на пустые строки и реализовать свое удобное окно сообщений.

"в результате пользователь скажет что ему "показали какую то ошибку""

От пользователя больше и не надо. Зная, когда и при каком действии возникла ошибка, специалист сможет найти в логе необходимую информацию.