[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ft] [ft-devel] Large code changes without changing functionality
From: |
Behdad Esfahbod |
Subject: |
Re: [ft] [ft-devel] Large code changes without changing functionality |
Date: |
Fri, 15 Mar 2013 03:26:19 -0400 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 |
What's the difference between FT_THROW and FT_ERR?
Why no FT_THROW here:
- error = FT_Err_Invalid_Argument;
+ error = FT_ERR( Invalid_Argument );
Confused.
behdad
On 13-03-15 03:21 AM, Behdad Esfahbod wrote:
> On 13-03-15 03:18 AM, Werner LEMBERG wrote:
>>
>>> Doesn't the c879f24562cc21bb062fb2faa86633a6c8c2371a change have API
>>> implications? Is the module error base visible to users?
>>
>> Thanks for catching this, fixed now in git. I doubt that many people
>> use module errors, however.
>>
>> The reason that I still support this is the possibility for more
>> improvements: For example, instead of having `module errors', I could
>> register each single source code file and assigning an ID to it. If I
>> now say that error codes are 32bit wide, the upper 16bit could hold
>> the line number, the next 8 bits a file ID and the lowermost bits the
>> real error code. This would be a quite effective means to find out
>> the source code origin of returned error codes even in non-debug
>> builds.
>
> It would, but I'd consider module errors an API mistake to begin with. For
> the past ten years everyone has been comparing FT error codes using good old
> equality operator. If no one uses a feature, there's no point developing it
> further. If anything, it should be removed.
>
> The FT_THROW facility on the other hand is extremely useful.
>
> behdad
>
--
behdad
http://behdad.org/