The Right Approach to Exceptions

Sean Kelly sean at
Mon Feb 20 12:57:00 PST 2012

I meant more that by ignoring the type matching system in favor of our own runtime convention we've prevented the compiler from doing any optimizations (or error checking) that may have been possible.

On Feb 20, 2012, at 12:15 PM, Juan Manuel Cabo wrote:

> 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.

More information about the Digitalmars-d mailing list