Same error #, different descriptions?
Related to my other question about error vs retern values, is it accepted,
encouraged, whatever to have different descriptions in an error with the
same error number? For example, let's say I have a business component with
an add method that validates several parameters before adding the new item.
If multiple parameters are invalid (i.e. password too short and last name
missing), should I raise an error for failed validataion, and in the description
list which fields were invalid, or is this not an accepted approach? The
other option I can think of is to raise a seperate error for each invalid
field, but then I can only catch one invalid parameter per method call.
P.S. I and my boss both ordered your book yesterday.
Re: Same error #, different descriptions?
It is fine to do the type of error code "sharing" that you propose. You are
really defining a single error, a field parameter error. Since you have
room in the Err object's properties for full disclosure of the exact error,
there will be more than enough opportunity for you to describe the details
of the error. Microsoft itself does this type of error code sharing in Visual
Basic. (Sometimes I think they share too many error codes, especially when
it comes to file access related errors, but that is another discussion.)
Thank you for your interest in The Visual Basic Style Guide.
Last Post: 07-11-2002, 09:59 AM
By Lisa in forum VB Classic
Last Post: 01-09-2002, 07:54 AM
Last Post: 06-28-2001, 02:16 AM
By Joseph Hicks in forum Database
Last Post: 04-17-2001, 01:55 PM
By Paul Hickey in forum Web
Last Post: 04-16-2001, 03:08 AM
Top DevX Stories
Easy Web Services with SQL Server 2005 HTTP Endpoints
JavaOne 2005: Java Platform Roadmap Focuses on Ease of Development, Sun Focuses on the "Free" in F.O.S.S.
Wed Yourself to UML with the Power of Associations
Microsoft to Add AJAX Capabilities to ASP.NET
IBM's Cloudscape Versus MySQL