Часто в приложениях ASP.NET можно встретить код, подобный следующему:
1 2 3 4 5 | if (Cache["SomeData"] != null) { string name = ((SomeClass) Cache["SomeData"]).Name; //..... } |
Опытный программист, даже если он не страдает паранойей, сразу видит возможную проблему — NullReferenceException. Все дело в механизме работы кэша в ASP.NET. В идеальном случае объект, помещенный в кэш, будет храниться там до перезагрузки приложения, но на практике он может быть удален между двумя обращениями: во время сборки мусора, если закончилась память (поскольку кэш использует слабые ссылки WeakReference); другим потоком, когда нужно перегрузить данные.
Соответственно приведенный код будет работать в 99% случаев, но периодически в логах будут появляться ошибки, которые практически невозможно повторить. Вот правильное использование кэша:
1 2 3 4 5 6 | SomeClass someClass = Cache["SomeData"] as SomeClass; if (someClass != null) { string name = someClass.Name; //..... } |
Не теряйте бдительности, они только этого и ждут! (о багах)
спасибо…частенько встречался с подобным багом и руки опускались из-за неопытности :)
я если честно не понял почему в первом случае может появиться NullReferenceException, ведь там проверка на null есть? и почему тогда не появится во втором.
Тоже не особо понял. Первый вариант часто приводится в различных книгах.
Использую первый вариант уже долгое время, никаких багов не замечал, к тому же всегда выставляю время хранения кэша. Обычно при пустом кэше происходит секундная заминка, но в целом все работает нормально.
Правильное использование кэша в ASP.NET…
Все дело в механизме работы кэша в ASP.NET. В идеальном случае объект, помещенный в кэш, будет храниться там до перезагрузки приложения, но на …