- Feature Articles
- CodeSOD
-
Error'd
- Most Recent Articles
- Nothing Doing
- Home By Another Way
- Coast Star
- Forsooth
- Epic
- The State of the Arts
- Planing ahead
- Too Spicy For My Hat
- Forums
-
Other Articles
- Random Article
- Other Series
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Edit Admin
Inside the returned dictionary, there's a key value pair containing another dictionary, and so on....
Edit Admin
For the younger generations here around, this article is about the old HttpSessionState class (https://learn.microsoft.com/en-us/dotnet/api/system.web.sessionstate.httpsessionstate?view=netframework-4.8.1).
Son in the spirit of ancient coding practices:
The second version is just stupid; that's not how indexer work in .net - there doesn't need to be an underlying type or a base type and assuming so even if implemented internally that way pretty much sets you up for future failure. And then if you wrap everything into an exception scope, you will never actually notice internal changes as well - the code just silently breaks and most likely the developer that has to fix that crap will /* insert most horrible murder method */ the person who wrote that initially.
Edit Admin
Let's also mention that this code doesn't really solve any problems.
The most likely bugs related to accessing Session data; the session has been reset and now the data isn't there, spelling error in session variable name, mishandling the data type. In addition, it would be really useful to easily determine where a particular session variable is used. Creating a method to get any session variable doesn't make any of these situations any easier to handle.
However, if you create a wrapper class and access session variables through it, then you can solve all of them. My most recent implementation of this end up looking like this when used:
var x = State.Session.LoginTime
This allows me to right click on the property and do "Find References" and get all (and only) the code that accesses this one session variable. It allows me to strongly type the property and to write any necessary conversion or access code only once. It allows me to handle the "no data" case on a variable by variable basis. Some should return empty strings if missing, some properties should be nullable, and maybe some should throw exceptions. It lets the compiler validate the variable name.
I can't tell you how many times I've seen these dumb wrapper classes that may reduce a bit of code replication, but don't solve any of the "real problems". The absolute worst part is that so many programmers don't even understand what problems are costing them the most time and creating the most bugs.
Admin
"...functions which are name RetrieveBlahAsType are generally an antipattern. Either there should be some generics, ..."
Generics didn't appear in .Net until version 2 so it's not impossible that this is framework 1.1 code that never got refactored.