What is the best way to read a SQL error return?

Question

What is the best way to read a SQL error return?

Navigation

#1 by (3 votes)
#2 by (1 votes)

1

What is the best way to read a sql server error return in a C # web form application?

I have the following ..

No sql server;

END TRY
BEGIN CATCH
    Raiserror('Erro ao gerar os dados', 18, 1);
      return;
END CATCH;

No c #

SqlCommand cmd = new SqlCommand();
cmd.CommandText = "minhapro";
cmd.Connection = conn;
cmd.CommandType = CommandType.StoredProcedure;
cmd.Parameters.AddWithValue("@Data", rdpDtMedicao.SelectedDate.ToString());
cmd.Parameters.AddWithValue("@Filial", Filial);
cmd.Parameters.AddWithValue("@UserId", cfg.UserID);
cmd.CommandTimeout = 1800;
SqlDataAdapter da = new SqlDataAdapter();
da.SelectCommand = cmd;
try
{
    conn.Open();
    var teste =  cmd.ExecuteNonQuery();
}
catch (Exception ex)
{
}
finally
{
    conn.Close();
}

I have already seen that ExecuteNonQuery returns an int , but I want it to be my error.

sql-server c# return webforms

asked by anonymous 29.10.2015 / 19:12

2 answers

1

Create a parameter to get the return of your SQL and add to the cmd parameters, something like:

SqlParameter p = new SqlParameter("@Nome", DbType.String);
p.Direction = ParameterDirection.Output; 

cmd.Parameters.Add(p);

And there in your SQL code you define the desired return on this variable. After ExecuteNonQuery you just get the contents of the variable back.

29.10.2015 / 19:33

Python doubts syntax What is the correct way to run an application on a linux server using PHP? [closed]

score 3 · Accepted Answer

You're hiding your error by doing this

catch (Exception ex)
{
}

Do not do this . Hiding the exceptions never is a good idea. Probably just getting this block catch will already help you a lot.

It is very common to think that "% -required programming" is a good option, but in fact exceptions should only be captured in specific cases when you know what (and how ) do after capturing them.

Another important thing, this code

BEGIN CATCH
    Raiserror('Erro ao gerar os dados', 18, 1);
    return;
END CATCH;

also does nothing very useful. You are hiding the real error and putting a "beautiful message". This is not ideal.

Imagine that this try-catch gives an error in the production environment, the error that the application will receive will be procedure/function , when in fact it should be informing you where and why the error occurred.

About your comment

in case of Raiserror error ('Error generating data', 18, 1); ... this will be shown to the user when he is to generate the data of a demo in the TextBox. I do not want to explode a msg error that the guy will not even know what it is.

Exceptions do not serve to inform something to the end user. They serve to show the developer that something is wrong. First it makes no difference whether or not the user knows what the error message is saying, it will remain an error message and it will not be able to do anything without the help of a support or the developer. Another important point is that if some exception is being thrown it is because there is some error in the code and the first thing you will want to do when you encounter an error is to fix it,

I can understand your intention not to scare the user with giant, code-in error messages in between. It's best if you capture the generic exceptions in the "top" layer of your application, something like the main screen, entry point, or something similar.

Take a look at Best way to handle Exceptions . There you have good answers on this subject.