Am 10.07.2017 15:46 schrieb "Graeme Geldenhuys" <[hidden email]>:
> On 2017-07-10 13:34, Dmitry Boyarintsev wrote:
>> are you referring to "Catching More Than One Type of Exception with One
>> Exception Handler" in
> Yes. You can have multiple catch blocks inside the same try block. You can also have a single catch block with a comma separated list of exception types.
You can catch multiple exception types in Object Pascal as well:
=== code begin ===
on e: EWhatever do ...;
on e: EFoobar do ...;
=== code end ===
Though you can't use the same code block for multiple types.
> Is this acceptable ?
>> 'SELECT Customers.CustomerName, Orders.OrderID' +
>> 'FROM Customers' +
>> 'FULL OUTER JOIN Orders' +
>> 'ON Customers.CustomerID = Orders.CustomerID' +
>> 'ORDER BY Customers.CustomerName;'
> I think that one have to insert space at some loactions:
> 'SELECT Customers.CustomerName, Orders.OrderID' +
> ' FROM Customers' +
> ' FULL OUTER JOIN Orders' +
> ' ON Customers.CustomerID = Orders.CustomerID' +
> ' ORDER BY Customers.CustomerName;';
> Cheers, Ched
And if it is a multiline string, the compiler may have to convert
carriage return/new line into a space for you, to allow it to take:
FULL OUTER JOIN Orders
and convert the carriage return after "Customers" into a space for you..
Re: Food for thought - language string improvement
In reply to this post by Free Pascal - General mailing list
Am 10.07.2017 um 15:00 schrieb Sven Barth via fpc-pascal:
> Am 10.07.2017 13:19 schrieb "Michael Van Canneyt"
> <[hidden email] <mailto:[hidden email]>>:
>> On Mon, 10 Jul 2017, Felipe Monteiro de Carvalho wrote:
>>> On Mon, Jul 10, 2017 at 1:08 PM, Michael Van Canneyt
>>> <[hidden email] <mailto:[hidden email]>> wrote:
>>>> The code is definitely not the same. In each case, it was measured.
> There is
>>>> a 10% performance loss.
>>> I'd love a source on this one. I guess you mean in Free Pascal?
>> The classes unit can be recompiled to use the fgl (well, that used to
> be so)
>> as a basis. When using the resulting list and stringlist, there was a 10%
>> performance loss. The main reason - If I recall correctly - was that
> the fgl needs to resort to move() operations instead of direct assignments.
> The fgl classes don't use Move(), but they have a virtual method that
> does the assignment between the specialized parameters that's inherited
> from the non-generic parent list type.