Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
| Author |
Topic |
|
Onamuji
Aged Yak Warrior
504 Posts |
 Posted - 2003-10-24 : 10:42:07
|
| [code]CREATE PROCEDURE dbo.SchemaClasses_Add ( @name VARCHAR(64), @description VARCHAR(2048), @disabled BIT) AS SET NOCOUNT ON DECLARE @error INT, @rowcount INT DECLARE @schemaClassID UNIQUEIDENTIFIER IF @name IS NULL OR LEN(@name) < 1 RAISERROR(250001, 10, 1, '@name') WITH SETERROR ELSE IF @description IS NULL OR LEN(@description) < 1 RAISERROR(250001, 10, 1, '@description') WITH SETERROR ELSE IF EXISTS(SELECT * FROM dbo.SchemaClasses WHERE Name = @name) RAISERROR(250002, 11, 1, 'SchemaClasses') WITH SETERROR SET @error = @@ERROR IF @error <> 0 GOTO SchemaClasses_Add_exit IF @disabled IS NULL SET @disabled = 0 SET @schemaClassID = NEWID() INSERT INTO dbo.SchemaClasses (SchemaClassID, Name, Description, Disabled) VALUES (@schemaClassID, @name, @description, @disabled) SELECT @error = @@ERROR, @rowcount = @@ROWCOUNT IF @error = 0 AND @rowcount <> 1 BEGIN RAISERROR(250004, 11, 2, @rowcount) WITH SETERROR SET @error = @@ERROR END IF @error <> 0 BEGIN IF @@TRANCOUNT > 0 ROLLBACK TRANSACTION GOTO SchemaClasses_Add_exit END SELECT SchemaClassID, Name, Description, Disabled FROM dbo.SchemaClasses WHERE SchemaClassID = @schemaClassID SELECT @error = @@ERROR, @rowcount = @@ROWCOUNT IF @error = 0 AND @rowcount <> 1 BEGIN RAISERROR(250004, 11, 3, @rowcount) WITH SETERROR SET @error = @@ERROR ENDSchemaClasses_Add_exit: RETURN @errorGO[/code] |
|
|
X002548
Not Just a Number
15586 Posts |
Posted - 2003-10-24 : 11:58:58
|
| I was gonna say NEVER...But is there a need to check things like SELECT @x = 1?OK...I'm gonna stick with never...Only because of how much non checking that goes on...Brett8-) |
 |
|
|
MakeYourDaddyProud
184 Posts |
Posted - 2003-10-24 : 12:15:37
|
| Wow, most of the code is taken up with @@error assignments. Bill G really needs to shake up the appalling need to write bloated code! One thing, have you borne in mind scope aborting errors that terminate the current batch since you can't trap these?Batch/Scope-abortion might be a problem if this proccie is being called by a higher level one since the return statement would never be executed.Daniel Small MIAPwww.danielsmall.com IT Factoring |
|
|
|
adweigert
Starting Member
22 Posts |
Posted - 2003-10-24 : 13:36:32
|
| that's fine if its a fatal error that causes the connection to be dropped i can handle that at the top ...the reason i check the actual rowcout after a select is to make sure the select returned data ... if it doesn't something very wrong happened ...the only reason i'm doing this level of error checking at this level is because i can't trust that the outside world will use my programming API - that also does a lot of checking so that these errors should never happen - to access the database or someone might get in and try to feed bad data into the database ... its really ugly ... wish yukon was sooner than it is going to be ... |
|
|
|
AjarnMark
SQL Slashing Gunting Master
3246 Posts |
Posted - 2003-10-27 : 14:33:43
|
quote:
Originally posted by danny2sweet
Wow, most of the code is taken up with @@error assignments. Bill G really needs to shake up the appalling need to write bloated code!
I believe Yukon will support try...catch syntax which should make everyone happier.And it's not really Bill Graziano's fault.  --------------------------------------------------------Visit the SQLTeam Weblogs at [url]http://weblogs.sqlteam.com[/url] |
|
|
|
|
|
|
|
|
When Is Too Much Error Handling A Bad Thing?