Click here to Skip to main content
15,116,813 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
See more:
I have a function as IEnumerable that fetch all data from a table in database by stored procdure using executereader but return null In the event that table have any record

What I have tried:

C#
public IEnumerable<adress_> GetAllAdress_()
        {
            try
            {
                List<adress_> lstadress_ = new List<adress_>();

                using (SqlConnection con = new SqlConnection(connectionString))
                {
                    SqlCommand cmd = new SqlCommand("spGetAllAdress_s", con);
                    cmd.CommandType = CommandType.StoredProcedure;

                    con.Open();
                    SqlDataReader rdr = cmd.ExecuteReader();

					while (rdr.Read())
                    {

						Adress_ adress_ = new Adress_();

						adress_.adressId = Convert.ToInt32(rdr["adressId"]);
                         adress_.persianAdress.ToString();
                         adress_.inhabitAdress.ToString();
                         adress_.adressInforigen.ToString();
                         adress_.branch.ToString();
                         adress_.postCode.ToString();
                         adress_.startDate.ToString();
                         adress_.endDate.ToString();


                        lstadress_.Add(adress_);
                    }
                    con.Close();
                }
                return lstadress_;
            }
            catch
            {
				return null;
            }
        }
Posted
Updated 7-Feb-21 9:13am
v2

A try-catch block is intended to catch an Exception, i.e. an object that describes what went wrong. You seem not interested in it.

:(
   
Comments
Ali Jafarinezhad 7-Feb-21 13:57pm
   
Your answer was irrelevant to my question
Quote:
Your answer was irrelevant to my question

No, it wasn't. Luc was absolutely spot-on, if a little terse - he probably assumed you knew what you were doing and would understand what he said.

Allow me to expand on his answer:
When you use a try...catch in your code and ignore the actual exception you throw away all the information that would tell you exactly what your problem is. You have a try block around the whole DB operation, but your catch block collects all exception types and discards them in favour of returning a null value.
So if your connection string is wrong - you return null.
If your SP doesn't exist - you return null.
If your SP fails - you return null.
If there is no column of that name returned - you return null.
If ... you get the idea.

If you aren't going to handle the error yourself, don't use a try...catch block. Returning a null error code is old-school: the modern thinking is that if you can't deal with it, let the exception filter up to a level that can. That way a multi-layer app can find a problem is -say- the data layer, and "bubble the exception up" through the Business layer to the Presentation layer which is the only one that can let the user know there was a problem - and still access the Exception object to tell him what the problem was!

With your method, your null return tells the calling method that something went wrong, but gives nobody any idea what it might have been!

Luc's answer wasn't irrelevant - you just didn't understand it.
   
Comments
Ali Jafarinezhad 7-Feb-21 14:27pm
   
Yes, you are right. My answer was a bit hasty. I apologize to Luc for this. I found the answer. In fact, I forgot to enter the second part of the phrase and I should have written like this
adress_.inhabitAdress = rdr ["inhabitAdress" ] .ToString ()
I wrote in a hurry and I think I wrote in a hurry and I think I should use it better from try-catch, thank you
Luc Pattyn 7-Feb-21 14:49pm
   
+5 good cop bad cop routine often works wonders...

:)
OriginalGriff 7-Feb-21 15:38pm
   
:D So who's the bad cop?
Luc Pattyn 7-Feb-21 15:50pm
   
I dunno.
The one that encourages reflection?
The one that interrupts and spoon feeds?
The one that provokes a non-stock reply?
OriginalGriff 7-Feb-21 16:15pm
   
Let's just blame Harry Callahan and not worry about it! ;D
Luc Pattyn 7-Feb-21 16:18pm
   
That's Tom Barnaby's twin brother, isn't he?
OriginalGriff 7-Feb-21 16:54pm
   
:D I'm always amazed anyone moves to Midsomer Norton: Population about 60, with 6 murdered every week ...

Off topic: it's good to see your name appearing on the "Top Experts" list - your wisdom has been sorely missed!
Luc Pattyn 7-Feb-21 17:18pm
   
There's only a few episodes per series, and they keep importing ex-wives, forgotten siblings, tourists, fresh nobility, strange cultists, and more potential victims, so Midsomer is doing well actually.

Top Expert? that is hard to believe, I only answer a few questions, I tend to pick the ones that I know something about AND show some potential. Which doesn't add up much. So I was quite surprised a few weeks ago when I received an email announcing another MVPship... Things must go really badly.

But you Sir, you're a rock.

:)
OriginalGriff 7-Feb-21 17:24pm
   
Check the QA page: https://www.codeproject.com/script/Answers/List.aspx?tab=unanswered
Right hand side, you're in second place for today.
Ignore me being at the top, that's always a misprint. I think I send the Hamsters too many fermented sunflower seeds ... :laugh:

I know what you mean though, there are too many posters that just aren't interested in getting an answer - they just want code they can hand in. :sigh:
Luc Pattyn 7-Feb-21 17:33pm
   
Sunflower seeds? Did you run out of kopi luwak? And they didn't notice?
OriginalGriff 7-Feb-21 17:43pm
   
Hah! Mere sunflower seeds run away screaming in terror when they see Chris's coffee machine!
https://www.codeproject.com/Messages/5775509/Re-Bean-to-cup-machines-Coffee-of-course

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)




CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900