Andy B. said:
That's fine except the data layer has no clue what error to look for.
Neither would the business logic directly. The only way to do something
like this is to put the decisions on what to display for user friendly
errors is in the UI. I am looking for certain errors since not all of them
apply to the context. An example is:
try
'The bulk of the code to insert a headline
Headlines.Insert(Headline)
catch ex as SqlException
'The only things that can happen here are:
'1. Unique constraint violation (There can't be 2 or more headlines with
the exact same title)
2. The database is unavailable for whatever reason like network issues or
server problems.
'-- Process unique constraint and show friendly error if needed
'-- Process other issues needing possible attention (network, server) see
#2 above).
end try
Would this be a better way of doing things?
In your example you would put the code for Headline.Insert into a DAL. In
that code you would capture the SqlException, find out what the error was
and then return an error (raiseerror is one way but I think making the
Insert a function returning an error code would be easier to code than using
errors). When you get a certain error in your DAL you can then return to
the user a more friendly message.
If your DAL doesn't know what it is doing then you are on the wrong track.
This code is where all database handling is done. You can then code the
application (GUI) to use those classes and recieve from them meaningful (to
the user) messages.
The number of thing that can go wrong will be a function of the complexity
of the code and the database.
If you are using something like SQL Server you could also code against
stored procedures. The procedure which is resident on the database server
would then be responsible for returning meaningful messages.
LS