The Right Approach to Exceptions

[Juan Manuel Cabo]

I agree to disagree.

But about your argument for efficiency, any check that you do when
examining an exception doesn't need to be lightning fast, after all,
if you are looking at an exception object, it means that the stack
got unwound, and any nano seconds that you spend doing this:

	catch (Exception ex) {
		if ("mycustomfield" in ex) {
			.. do something ..
 		}
	}

which is just an "in" check in an associative array, which might never
have more than 10 elements (so even linear search is appropiate),
is overshadowed by the time that the runtime took to unwind the stack
and serve the exception to your catch block.

--jm


On 02/20/2012 05:05 PM, Sean Kelly wrote:
> On Feb 20, 2012, at 11:54 AM, Juan Manuel Cabo wrote:
> 
>> About this part:
>>
>>>> What you want is throw a COMException and link it to the original
>>>> Exception. You have to consider Exception as a linkedlist, one
>>>> being the cause of another.
>>
>> The Variant[string] is an idea to help avoid people creating new kinds
>> of exception types that don't add nothing.
> 
> I don't think this makes sense.  To effectively use whatever's in the table I pretty much have to know what error I'm handling, and this isn't possible if type information is lost.  Unless this determination is moved to a run-time check of some field within the exception, and then I'm making my code that much messier and less efficient by putting in tests of this identifier against a list of constants.  Personally, I don't see any use for this table beyond providing context, much like we already have with file, line, etc.