If not null, return value else return null
-
Only the comment after the method declaration is not mine. Some things have been changed to protect the innocent:
// Why return a "Foo" object type when we can just return a datatable?
// We do have the type but unpacking it is just *so tiresome*.
// As is writing a proper DAL or using one of the many free ORMs etc.
public DataTable Get_Foo_ByID(int memberID)//MethodID #210
{
try
{
string query = "SELECT DISTINCT * FROM Foo WHERE bar=" + barId;// I hope we don't have little Bobby tables as a member!
DataTable dt = Utils.ExecuteReader(query);
//Because we just have too many processor cycles dagnammit:
if (dt != null)
{
return dt;
}
else
{
return null;
}
}
//Somebody has been reading a book about catch errors on database calls.
// Pity they didn't get to the advice about not catching all exceptions
catch (Exception ex)
{
// Why is it #210? Beacuse the comment next to the method declaration says it is, that's why!
// No need to deal with pesky stack-traces with their confusing line numbers or useful additions to the error message!
throw new Exception("MethodID:= #210, Error:=" + ex.Message);
}
}This sort of thing is repeated many times due to the delights of cut-and-paste. We've also cunningly embedded our data access stuff in our object models, no need to look in more than one place! We've not made any attempt at making Data Access easy for ourselves with proxy classes etc. Mutters....
Sort of a cross between Lawrence of Arabia and Dilbert.[^]
-Or-
A Dead ringer for Kate Winslett[^] -
Only the comment after the method declaration is not mine. Some things have been changed to protect the innocent:
// Why return a "Foo" object type when we can just return a datatable?
// We do have the type but unpacking it is just *so tiresome*.
// As is writing a proper DAL or using one of the many free ORMs etc.
public DataTable Get_Foo_ByID(int memberID)//MethodID #210
{
try
{
string query = "SELECT DISTINCT * FROM Foo WHERE bar=" + barId;// I hope we don't have little Bobby tables as a member!
DataTable dt = Utils.ExecuteReader(query);
//Because we just have too many processor cycles dagnammit:
if (dt != null)
{
return dt;
}
else
{
return null;
}
}
//Somebody has been reading a book about catch errors on database calls.
// Pity they didn't get to the advice about not catching all exceptions
catch (Exception ex)
{
// Why is it #210? Beacuse the comment next to the method declaration says it is, that's why!
// No need to deal with pesky stack-traces with their confusing line numbers or useful additions to the error message!
throw new Exception("MethodID:= #210, Error:=" + ex.Message);
}
}This sort of thing is repeated many times due to the delights of cut-and-paste. We've also cunningly embedded our data access stuff in our object models, no need to look in more than one place! We've not made any attempt at making Data Access easy for ourselves with proxy classes etc. Mutters....
Sort of a cross between Lawrence of Arabia and Dilbert.[^]
-Or-
A Dead ringer for Kate Winslett[^]That if/else is a classic anti-pattern that I have seen far too many times as is the catch everything clause. However, giving the exception a MethodID number is not something I have seen very often, clearly this person is inventive. And I am sure that the Method ID will be of great use to the end user. ;) Copy and paste inheritance is in use everywhere. I'm even guilty of using that myself sometimes to get something working quickly. But, overall this code example is a classic horror.
Just because the code works, it doesn't mean that it is good code.
-
Only the comment after the method declaration is not mine. Some things have been changed to protect the innocent:
// Why return a "Foo" object type when we can just return a datatable?
// We do have the type but unpacking it is just *so tiresome*.
// As is writing a proper DAL or using one of the many free ORMs etc.
public DataTable Get_Foo_ByID(int memberID)//MethodID #210
{
try
{
string query = "SELECT DISTINCT * FROM Foo WHERE bar=" + barId;// I hope we don't have little Bobby tables as a member!
DataTable dt = Utils.ExecuteReader(query);
//Because we just have too many processor cycles dagnammit:
if (dt != null)
{
return dt;
}
else
{
return null;
}
}
//Somebody has been reading a book about catch errors on database calls.
// Pity they didn't get to the advice about not catching all exceptions
catch (Exception ex)
{
// Why is it #210? Beacuse the comment next to the method declaration says it is, that's why!
// No need to deal with pesky stack-traces with their confusing line numbers or useful additions to the error message!
throw new Exception("MethodID:= #210, Error:=" + ex.Message);
}
}This sort of thing is repeated many times due to the delights of cut-and-paste. We've also cunningly embedded our data access stuff in our object models, no need to look in more than one place! We've not made any attempt at making Data Access easy for ourselves with proxy classes etc. Mutters....
Sort of a cross between Lawrence of Arabia and Dilbert.[^]
-Or-
A Dead ringer for Kate Winslett[^]