FG:

> Strange. No problems here. Only had to switch from dmd32 to gdc64 with 1GB or bigger files. Tested on win7-64.

How much memory is it using? What's the performance compared to the diff tool?

Bye,
bearophile

On 2013-01-31 15:17, bearophile wrote:
> FG:
>
>> Strange. No problems here. Only had to switch from dmd32 to gdc64 with 1GB or
>> bigger files. Tested on win7-64.
>
> How much memory is it using? What's the performance compared to the diff tool?

Two identical files, 1069 MB each. Program compiled with GDC, 64-bit.
Used 6272 kB private mem / 2144 MB working set, and took 13.5 seconds.
Cygwin's diff took only 1.85 s.

On 01/31/2013 12:42 AM, Roumen Roupski wrote:

> catch (Throwable ex)
> {
> writefln("File read error: %s", ex.msg);
> return false; // cannot compare the files

Throwable is a little too high in the exception hierarchy:

    Throwable
    /      \
Error    Exception
 /  \      /   \

A program should catch only Exception and its subtypes. The Error sub-hierarchy represents errors about the state of the program. The program state may be so invalid that it is not guaranteed that even writefln() or 'return' will work.

For the same reason, if it is really an Error that has been thrown, even the destructors are not called during stack unwinding.

Ali

On 1/31/13, Ali Çehreli <acehreli@yahoo.com> wrote:
> For the same reason, if it is really an Error that has been thrown, even the destructors are not called during stack unwinding.

Where are you extracting this information from?

On 01/31/2013 10:39 AM, Andrej Mitrovic wrote:
> On 1/31/13, Ali Çehreli<acehreli@yahoo.com>  wrote:
>> For the same reason, if it is really an Error that has been thrown, even
>> the destructors are not called during stack unwinding.
>
> Where are you extracting this information from?

I hope I haven't spread wrong information. I "learned" this from the discussions on this forum. Perhaps it was merely an idea and I remember it as truth.

Others, is what I said correct? Why do I think that way? :)

Ali

On 01/31/2013 09:43 PM, Ali Çehreli wrote:
> On 01/31/2013 10:39 AM, Andrej Mitrovic wrote:
>  > On 1/31/13, Ali Çehreli<acehreli@yahoo.com>  wrote:
>  >> For the same reason, if it is really an Error that has been thrown,
> even
>  >> the destructors are not called during stack unwinding.
>  >
>  > Where are you extracting this information from?
>
> I hope I haven't spread wrong information. I "learned" this from the
> discussions on this forum. Perhaps it was merely an idea and I remember
> it as truth.
>
> Others, is what I said correct? Why do I think that way? :)
>
> Ali
>

Destructors are not "guaranteed" to run. They actually do. I think this is mostly to allow segmentation faults on Linux.

On 01/31/2013 12:43 PM, Ali Çehreli wrote:
> On 01/31/2013 10:39 AM, Andrej Mitrovic wrote:
>  > On 1/31/13, Ali Çehreli<acehreli@yahoo.com> wrote:
>  >> For the same reason, if it is really an Error that has been thrown,
> even
>  >> the destructors are not called during stack unwinding.
>  >
>  > Where are you extracting this information from?
>
> I hope I haven't spread wrong information. I "learned" this from the
> discussions on this forum. Perhaps it was merely an idea and I remember
> it as truth.
>
> Others, is what I said correct? Why do I think that way? :)

I tested this with dmd. struct destructors do get called during stack unwinding.

However, a relevant quote:

  http://dlang.org/phobos/object.html#.Exception

"In principle, only thrown objects derived from [Exception] are safe to catch inside a catch block. Thrown objects not derived from Exception represent runtime errors that should not be caught, as certain runtime guarantees may not hold, making it unsafe to continue program execution."

TDPL talks about what happens (and does not happen) when a function in declared as nothrow. It also talks about why Throwable should not be caught. It doesn't say the same exact things about Error but the book draws a clear distinction between the Exception sub-hierarchy and the other exception classes.

There is great information in Chapter 9 of TDPL but they are quite large to type here. Especially sections 9.2 and 9.4 are relevant.

The following are my thoughts...

Here is the logic behind why the destructors must not be executed when the thrown exception is an Error. AssertError is an Error, indicating that the program state is wrong. When the program state is wrong, there is no guarantee that any further operation in the program can safely be executed.

Assume that the AssertError is coming from the invariant block of a struct (or assume that any other assert about the state of an object has failed). In that case the object is in a bad state. Can the destructor be called on that object? Should it be? What can we expect to happen?

Ali

On Thursday, 31 January 2013 at 20:43:37 UTC, Ali Çehreli wrote:
> On 01/31/2013 10:39 AM, Andrej Mitrovic wrote:
> > On 1/31/13, Ali Çehreli<acehreli@yahoo.com>  wrote:
> >> For the same reason, if it is really an Error that has been
> thrown, even
> >> the destructors are not called during stack unwinding.
> >
> > Where are you extracting this information from?
>
> I hope I haven't spread wrong information. I "learned" this from the discussions on this forum. Perhaps it was merely an idea and I remember it as truth.
>
> Others, is what I said correct? Why do I think that way? :)
>
> Ali

There is not much information about this topic, but I believe there are two separate issues here (technical and practical):

1) Errors can behave not always like exceptions. For example, most errors (which are not thrown directly) are generated by D features: final switch throws SwitchError, notorious activity inside class dtors which calls GC causes InvalidMemoryOperationError, etc. These are typically called  as OnXXError functions and are in druntime (https://github.com/D-Programming-Language/druntime/blob/master/src/core/exception.d). Theoretically this functions may just terminate application without throwing exception, so point here is that even trying to catch Error can be useless. However if Error is thrown by D exception mechanism, I think you can handle it just like other Throwables.

2) Although you can (sometimes) catch Error, state of the program is in unpredictable condition. These conditions may depend on type of error and other factors.