Click here to Skip to main content
15,880,725 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 8: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.

:(
 
Share this answer
 
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.
 
Share this answer
 
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    
+5good cop bad cop routine often works wonders...

:)
OriginalGriff 7-Feb-21 15:38pm    
:DSo 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

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