Best practice for letting VB know that your method throws an exception

[Justin115]

In my SQL data access layer in a VB 2005 class library, I have a few blocks which fit the following pattern:

try
    execute SQL command
catch DataException
    process exception (log it, etc.)
    generate and throw new DataException
      (with the original exception as an inner exception)
end try

return data

Since the catch block for each exception is largely the same, I've put that logic in a subroutine which ends by throwing the new exception I've generated.

Visual Basic, however, doesn't know that my sub throws an exception, so it gives me warnings about the return statement outside the try/catch block. I can easily turn off the warnings or even put an (unreachable) return statement within the catch block, but that seems like a hack.

I'd like to know if there's a best practice for this pattern. Maybe there's some attribute I can't find that alerts the compiler that a method throws an exception? Can I suppress the warnings within this particular class?

Thanks in advance for your help.

 

[chiph]

This is a valid warning -- it's telling you that you might return an uninitialized variable if an exception is thrown.

The solution would be to initialize Data outside the try..catch block to something that would be reasonable to return in the event of an exception.

Chip H.


____________________________________________________________________
If you want to get the best response to a question, please read FAQ222-2244 first

 

[Justin115]

I won't be returning anything in the event of the exception--I'll be throwing another exception--so should I really be pretending that I might return that uninitialized value? Setting the return values to null (duh!) is definitely better than anything I'd thought of, but it still isn't particularly satisfying. I want VB to warn me if I could possibly return that uninitialized variable, and I could feasably miss a valid warning by return values to null.

Ideally, I guess I'd like to write my code like this (it also gives me a warning, even though I know the method won't terminate without returning anything):

...

try
    execute SQL command
    return data
catch DataException
    process exception (log it, etc.)
    generate and throw new DataException
      (with the original exception as an inner exception)
end try

end function

I mean, when I actually have the throw statement within the catch block, rather than within a method called from the catch, VB doesn't have a problem with either of the patterns.

 

[BrianB]

initialize data as null and the compiler will stop complaining.

Brian Begy
BugSentry - Automatic error reporting for .NET and COM

http://www.bugsentry.com