Раньше у меня было своё отображение сообщений об ошибках, но почему-то вдруг всё сбилось (хотя настройки не менял) и стала отображаться полная информация об исключении, типа такой, как показана на картинке.

Настройки веб-конфига такие:

<customErrors mode="Off" />

<compilation debug="false"

Ошибки перехватываю в Global.asax в методе Application_Error. В нём формируется лог, который пишется на сервере, и сообщение для пользователя, которое отображается на специальной странице через направление на специальный контроллер и действие:

this.Response.Redirect("/Error/ErrorPage");


Так вот, раньше всё работало. Пришёл сегодня, покодил немного (вышеупомянутые настройки не менял) - лог перестал писаться, перенаправление не работает, зато вот эту дефолтную байду, что на картинке, показывает. При этом на изменение compilation debug не реагирует. Делал ребилд проекта - не работает.

Ага! Нашёл строчку, что это натворила. Когда писал лог (всё в том же методе Application_Error), добавил строчку




где sb - предварительно созданный в том же методе StringBuilder.

Как это может к такому привести?! О_о

Не, я, конечно, щас раскрою эту строчку и по строчке отслежу, но...



...Пока такая догадка - при возникновении ошибки в самом Application_Error, отображается вот то, что на картинке, несмотря на все compilation debug="false".

ctx - это HttpContext ctx = this.Context;

Так, всё, решил
http://stackoverflow.com/questions/17521277/http-x-forwarded-for-missing-from-servervariables-in-c-sharp .

Надо проверять наличие такой переменной. Но всё же странно, почему при возникновении ошибки в Application_Error показывается подробная информация об исключении даже при compilation debug="false"?

МСУuser7320

Что это за гавнокод?
А что не так? Достаю переменную из сервера ( в ней адреса ), разделяешь адреса по разделителю и каждый адрес логируешь (сначала в стринг билдер, затем весь билдер - в лог).

МСУuser7320, учи Linq. Зачем делать лишний цикл ToList, а потом заново по нему бегать?

http://msdn.microsoft.com/ru-ru/library/system.linq.enumerable.aggregate(v=vs.110).aspx



А если стринг билдер создан ранее и там уже много других строк?

hVosttМСУЗачем делать лишний цикл ToList, а потом заново по нему бегать?

кстати, ToList был сделан ради ForEach я так понимаю )) но всё равно говнокод, да.
Да, ради. Да, говнокод.

Просто первое, что пришло в голову - аналог форича, но не хотелось городить цикл. Почему метод (именно метод) ForEach есть только у списков и массивов? Его неплохо бы для всех коллекций сделать, чтобы потом удобно, в одну строку лямбдами проходиться по ним. На StackOverflow есть даже примеры подобных циклов как расширяющих методов, а в сам .NET почему-то не завезли.

Впрочем ...

Есть ещё такие извращения через селект http://stackoverflow.com/a/9092364/808128

user7320Есть ещё такие извращения через селект http://stackoverflow.com/a/9092364/808128
Как у Хвоста.

Вобщем, всем спасибо. Сделал как у Хвоста - с Replace.

А Aggregate вот где нашёл удобно применять - для итераций с дествием по NameValueCollection. Только я раньше делал с Select, а теперь с Aggregate. Например, есть у нас коллекция NameValueCollection. Надо пройтись по ней и что-нибудь с ней сделать. Раньше я делал так (пример с параметрами формы, sb - стринг билдер, созданный ранее)





а теперь делаю так




Ну, как вам мои лямбды? Кто тут говорил, что за лямбды бьют?

Кстати, не помню, нафига я использовал раньше KeyValuePair. В первом случае можно было обойтись одним селектом и аналогичной лямбдой, как во втором случае. Наверное, тупо передрал пример, не подумав.

hVosttuser7320На StackOverflow есть даже примеры подобных циклов как расширяющих методов, а в сам .NET почему-то не завезли.

дело в том, что LINQ это язык запросов (все методы расширения должны возвращать значение(я)). расширение ForEach не нужен, так как есть прекрасные нативные for(in) и for(;;), которые подходят лучше. вот где действительно уместно применение такой конструкции, это Parallel.ForEach
Да я и сам привёл ссылку на ссылку на Липперта. Насколько я понял, там философские рассуждения. Просто они (Липперт и Ко, которые рулили созданием Дотнета) решили сделать вроде как самый оптимальный для всех случаев вариант. Но есть и много случаев, когда такой вот форич в виде метода очень даже подошёл бы. Можно, конечно, циклом, но метод с лямбдой - короче и сахарнее.

hVosttuser7320,

рекомендую обзавестись привычкой вложенные проперти сохранять в локальную переменную и потом работать с ней:




дело в том, что никто не гарантирует, что свойство каждый раз не вычисляется (хотя вроде как все должны понимать, что это плохой тон, да и Рихтер неоднократно вычисляемые проперти обругивал).

к тому же код чище и лучше подвержен сопровождению.
Не понял, причём тут вычисляемые свойства? Тут же поля формы.

hVosttuser7320Но есть и много случаев, когда такой вот форич в виде метода очень даже подошёл бы.

дело не в филосовских рассуждениях. LINQ это язык запросов. соответственно для программиста, который будет читать и поддерживать код, должно быть как минимум кристально очевидно, что цепочка возвращает какой-то результат. даже результат работы Aggregate надо присваивать по-любому, а не паразитировать на "текучем" свойстве того же StringBuilder.
Т. е. когда надо пройтись методом по каждому элементу коллеции, то, по-вашему, лучше использовать обычный цикл, чем "метод, который проходит по всем элементам коллекции, с лямбдой"? И при этом это правильно не с точки зрения выполнения кода программы, а с точки зрения чтения и понимания кода другим программистом? Поэтому чисто технически ничего не мешает сделать форич для коллекций в виде расширяющего метода или ещё чего (на том же StackOverflow есть много простейших реализаций), но вот философия не позволяет?

Я же и говорю - философия. Достаточно поменять одно слово в определении LINQ (query... ну или понимать его шире, чем просто запрос, на который должен прийти ответ), и проблемы как не бывало. Да?

hVosttuser7320Не понял, причём тут вычисляемые свойства? Тут же поля формы.

ещё раз. SomeObject.SomeProperty.SomeSubProperty и т.д. надо загонять в локальную переменную, если требуется к свойству SomeSubProperty обращаться в теле метода более одного раза. такая мелочь, а выдаёт новичка с головой.
Перестраховка? Или традиции и "философия общего случая" и "надо делать универсально"?

Так ведь это свойство измениться не может - мне на сервер форма со своими значениями "приехала" от клиента и там всё жёстко забито. Поэтом в данном конкретном случае я не вижу причины заводить отдельную переменную для считываемых полей. А вот в тех случаях, когда во время чтения могут поменяться значения - да, надо бы "зафиксировать момент". Но и тогда может быть нужно, чтобы считывались именно текущие значения полей, а не зафиксированные на какой-то момент.

Я к тому, что это всё от случая зависит, а вы как бы хотите подвести общее правило - "делать так всегда и везде". Да?

hVosttuser7320Я к тому, что это всё от случая зависит, а вы как бы хотите подвести общее правило - "делать так всегда и везде". Да?

нет, я всего лишь порекомендовал обзавестись полезной привычкой, если имеется желание когда-нибудь в обозримом будущем поработать над разработкой проектов в команде.
А что, когда проекты в команде, то везде и всюду фичекат? "Так, эти средства языка не используем - это слишком голову засоряет", "Тут лямбды не надо... и вообще лямбды не надо - у нас за них бьют", "Элементы коллекций менять только циклом. А Линк у нас вообще забанен на уровне кастомного дистрибутива Дотнета, из которого он выкинут"?

hVosttuser7320,

в защиту новшевств добавлю, что когда прикрутили LINQ, ещё долгое время основная масса боялась его серьёхно использовать, предпочитая обычные циклические конкструкции для перебора элементов. да и сейчас ещё не каждый способен написать на LINQ что-нибудь по-сложнее обычного фильтра и конверта. однако уже повадились с гордостью писать свои кул-расширения типа ForEach, предварительно скопипастив кусок со StackOverflow...
"Боятся использовать" - муахаха! Так и сказали бы, что не слезают с заказчиков, которые на 2.0 всё заказывают и на XP без сервис паков сидят - думают, что деньги экономят.

"Бояки" тупо ленятся учить что-то новое. Зато знатно работают в командах - наверное, из тиммитингов-говорилен не вылезают, бездельники хреновы.