The Right Approach to Exceptions

[Piotr Szturmaj]

Walter Bright wrote:
> On 2/18/2012 3:13 PM, Andrei Alexandrescu wrote:
>> On 2/18/12 4:26 PM, Jonathan M Davis wrote (abridged):
>> GetOptException
>> FlagArgumentMissingException
>> InvalidFlagArgumentException
>> UnknownFlagException
>> FileException
>> FileNotFoundException
>> NotFileException
>> NotDirException
>> AccessDeniedException
>>
>> I died inside a little.
>
> I think typed exceptions are a good idea, but something looks wrong with
> these.
>
> (Also, having a large number of exception types is going to produce a
> lot of program size bloat. Remember, for EVERY class type, you've got
> the vtbl[], the .init data, and the TypeInfo. Going to town on exception
> types can really add this up.)

I feel that druntime might be optimized.

1) I think most of the bloat comes from .init data. For example this 
program:

class A
{
     ubyte[1024 * 1024 * 10] tenMegabytes;
}

class B : A {}
class C : B {}
class D : C {}

void main() { }

compiles to 40 MB exe under windows. Every class has copy of the same 10 
MB .init data.

I wonder why init is byte[] array. IMHO the better thing would be making 
it byte[][], i.e. array of byte arrays. Then some derived parts may be 
shared as byte array slices. This maybe little slower because it adds 
another level of indirection.

By the way, current byte[] array solution doesn't speed up void 
initializers, because it always overwrites void fields. This simple program:

import std.stdio;
class A { ubyte[8] test = void; }
void main() { writeln((new A()).test); }

always prints [0, 0, 0, 0, 0, 0, 0, 0].

With byte[][] array, some slices may have null ptrs so they may be 
initialized using memset() or not initialized at all (when using void 
initializer).

2) vtbl[] might also be shared for derivation chains that don't override 
any functions. But that may slow down program start, because vtables 
must be constructed at runtime.

Please correct me if I'm wrong :) I think that the use of classes should 
not be limited because of implementation issues. For me it's purely 
implementation issue, and I suppose it may be addressed with more 
optimized ABI or druntime.