Сьогодні мене питається однокурсник, чи ніколи в мене такого не було, щоб Response.Redirect відправляв кудись не туди, наприклад резолвив тильду в якийсь локальний шлях...

Ні, ніколи не було... Читай гугл.

Почитав... розказує. Виявляється, в нього той Response.Redirect був засунутий в блок try виду

try
{
...
}
catch(Exception)
{
...
}

Response.Redirect викликає Response.End який сроває ThreadAbortException...
І усьо. Капець.
Після того ішла довга розмова на тему, чому такий код поганий....
Мораль - ловіть тільки свої ексепшени, і буде вам щастя.

зтикався з цією ж проблемою на минулому свому проекті, трай-кетчі юзали такі самі (ідеалогія замовника була така). Короче щоб код ексепшен не сровав тре другим аргументом в редірект false передавати або можна редірект помістити в самому низу після трайкетча, бо в обробці самого редіректа особливого змісту немає

Я взагалі-то писав це по спогадах про розмову з тобою, тіко не помнив, шо то був ти))))

Ладно... Бачу, тре розжувати, чому треба ловити тільки свої експешени...
Ексепшен - це не є регулярна ситуація, що відображається в назві.
Відповідно, в загальному випадку, якщо стається якийсь експепшен, обробляти його не треба - бо це непердбачена ситуація.
Якщо ж в якомусь конкретному випадку нам треба, щоб апплікуха не впала, ми чекаємо на ситуацію, і збираємся її обробляти - ми знаємо, що в нас має впасти.
Тому ловимо те, що має падати.
Якщо ми наприклад чекаємно на ділення на нуль, то ловити треба DivideByZeroException, а не Exception... Якщо наприклад ми всередині try-catch оператора, який ловить все напишемо безконечну рекурсію, то програма впаде по OutOfMemory або по StackOverflow. В той же час ми його спокійно схаваєм і підемо далі... Які можуть бути наслідки - судіть самі.
Єдиний випадок, з мої кар'єри, в якому можна (і треба) було писати catch (Exception) - це був Win32-сервіс, обробка ексепшенів на глобальному рівні.
Якщо шось впало - акуратно зберегти в лог, а тоді продовжувати.

А отак, як в вище згаданому випадку - це типовий HowNotTo!

Сьогодні мій колега по тіму вбив цілий день на пошук одної баги... Яка виникла з пустого місця.
Отож. Написав він кусок функціоналу, в якому використав ще одну контролу з Ajax Control Toolkit.
Написав, задеплоїв на тестовий хост. На серваку криво рендериться, випадайка не випадає, а малюється жостко. Ну починаєм думати, якого фіга воно криво рендериться.
Дивимся - там стоїть фреймворк 3.5, а в нас на машинах - 3.5SP1. Hу думаєм - через сервіс пак. Але ставити сервіс-пак на продакшн сервер (в нас поки-що тестовий і продакшн серваки - одна і та сама машина) від фонаря - фігово.
Давай став на віртуал пісі 3.5, тесть. Знайшли образ сервака 2003го, поставив на нього фреймворк, похарився з настройками - готово. Працює, як має бути...
Фак. Тут раптом помічає, що стоїть 3.5SP1. WFT??? Адміни виявляється замість 3.5 дали 3.5 вже з сервіс паком. Наша пєсня хараша, начінай с начала...
Поставили вже гарантовано 3.5, без сервіс пака. ПРАЦЮЄ.
Втихаря матюкнулись, і полізли на сервак. Подумали.
На сусідньому серваку стоїть 3.5SP1. Перекинули туди. Знову криво.
Значить SP не винен.
Що ше відрізняється... База? Окей... Дамп, скрипт, компер... Одну сторку не задеплоїли. Взагалі.

В проекті всюди понатикувано try...catch'ів. Один з них тупо хавав еррору з відсутньою сторкою... От вам і секс.

try...catch треба грамотно організовувати і не хавати все підряд, як на мене то навпаки, краще побільше нагора видавати і розбиратись на верху.

Ну власне про що і тема.