On Wednesday, 12 February 2014 at 01:08:42 UTC, bearophile wrote:
> Is it possible to use a lazy argument there?

I think it depends on the task. To just wrap generic code though a delegate seems most straightforward.

> And isn't it better to catch Exception only?

Perhaps, or the specific FailException type or whatever.

On 2/11/2014 6:35 PM, Sean Kelly wrote:
> Throw a static exception (maybe even derived directly from Throwable),

I assume then that throwing something directly derived from Throwable would still run cleanup code (like scope guards and finally) like throwing Exception would? Or is it like throwing an Error, skipping cleanup code?

On 2/11/2014 6:35 PM, Sean Kelly wrote:
> Throw a static exception (maybe even derived directly from Throwable),
> similar to OutOfMemory, with a custom toString.  That should eliminate
> the formatting you don't like and will prevent the trace from occurring
> as well (see rt/deh.d in Druntime--the trace isn't run if you throw
> typeid(t).init.ptr).

Hmm, my custom toString isn't being executed. Am I doing something wrong here? Same result if I inherit direct from Throwable instead of Exception.

class Fail : Exception
{
    private this()
    {
        super(null);
    }

    private static Fail opCall(string msg, string file=__FILE__, int line=__LINE__)
    {
        auto f = cast(Fail) cast(void*) Fail.classinfo.init;

        f.msg  = msg;
        f.file = file;
        f.line = line;

        return f;
    }

    override string toString()
    {
    writeln("In Fail.toString()");
        return "someapp: ERROR: "~msg;
    }

}

void fail(string msg, string file=__FILE__, int line=__LINE__)
{
    throw Fail(msg, file, line);
}

void main()
{
    fail("Shit/fan collision detected.");
}

Output:
scriptlike.Fail@scriptlike.d(106): Shit/fan collision detected.

On Wednesday, 12 February 2014 at 02:41:34 UTC, Nick Sabalausky
wrote:
> On 2/11/2014 6:35 PM, Sean Kelly wrote:
>> Throw a static exception (maybe even derived directly from Throwable),
>
> I assume then that throwing something directly derived from Throwable would still run cleanup code (like scope guards and finally) like throwing Exception would? Or is it like throwing an Error, skipping cleanup code?

Everything runs cleanup code right now, unless someone changed
things on me.  But if a change were made, I'd say that only Error
and its children would skip cleanup.  The default would be to
perform cleanup.  That lets users create their own exception
hierarchies.

On Wednesday, 12 February 2014 at 03:31:38 UTC, Nick Sabalausky
wrote:
>
> Hmm, my custom toString isn't being executed. Am I doing something wrong here? Same result if I inherit direct from Throwable instead of Exception.
>
> class Fail : Exception
> {
>     private this()
>     {
>         super(null);
>     }
>
>     private static Fail opCall(string msg, string file=__FILE__, int line=__LINE__)
>     {
>         auto f = cast(Fail) cast(void*) Fail.classinfo.init;
>
>         f.msg  = msg;
>         f.file = file;
>         f.line = line;
>
>         return f;
>     }
>
>     override string toString()
>     {
>     writeln("In Fail.toString()");
>         return "someapp: ERROR: "~msg;
>     }
>
> }

It looks like this has changed, and the method that's called now
is:

void toString(scope void delegate(in char[]) sink) const;

I suspect this has broken a lot of custom exception messages,
since everything in core.exception still uses toString() for its
output.

On 2/12/2014 4:14 PM, Sean Kelly wrote:
>
> It looks like this has changed, and the method that's called now
> is:
>
> void toString(scope void delegate(in char[]) sink) const;
>
> I suspect this has broken a lot of custom exception messages,
> since everything in core.exception still uses toString() for its
> output.

Hmm, that still isn't getting called for me either:

void toString(scope void delegate(in char[]) sink) const
{
import std.stdio;
writeln("In Fail.toString()");
    sink("someapp: ERROR: "~msg);
}

Tried on both 2.064.2 and 2.065-b3.

Could it be that the custom toString just doesn't get run for static exceptions?

On Wednesday, 12 February 2014 at 22:42:45 UTC, Nick Sabalausky
wrote:
>
> Hmm, that still isn't getting called for me either:
>
> void toString(scope void delegate(in char[]) sink) const
> {
> import std.stdio;
> writeln("In Fail.toString()");
>     sink("someapp: ERROR: "~msg);
> }
>
> Tried on both 2.064.2 and 2.065-b3.
>
> Could it be that the custom toString just doesn't get run for static exceptions?

It should.  I'm not entirely sure why it isn't working.  For
reference, the relevant code is in rt/dmain2.d (printThrowable)
and object_.d (toString(sink)) in Druntime.

On 2/12/2014 6:14 PM, Sean Kelly wrote:
> On Wednesday, 12 February 2014 at 22:42:45 UTC, Nick Sabalausky
> wrote:
>>
>> Tried on both 2.064.2 and 2.065-b3.
>>
>> Could it be that the custom toString just doesn't get run for static
>> exceptions?
>
> It should.  I'm not entirely sure why it isn't working.  For
> reference, the relevant code is in rt/dmain2.d (printThrowable)
> and object_.d (toString(sink)) in Druntime.

Argh, there seems to be something wonky with the new RDMD in 2.065-b3 (or hopefully it's just my system):

If I use the RDMD from 2.064.2 to invoke DMD 2.065-b3 then this all works fine (thanks!). But if I use the RDMD/DMD *both* from DMD 2.065-b3 then...I dunno, either the exe doesn't get actually get rebuilt even with --force, or maybe it does but then runs an older copy of the exe, or something screwy like that. I need to look into that more.

Looks like it's *not* going to work with DMD 2.064.2 though. In that version, printThrowable never actually calls Throwable.toString (*any* version of toString for that matter), and the sink version of Throwable.toString doesn't even exist. That's fine though, at least I know it'll work staring with 2.065.

On 2/13/2014 2:55 AM, Nick Sabalausky wrote:
> But if I use the RDMD/DMD *both* from DMD 2.065-b3
> then...I dunno, either the exe doesn't get actually get rebuilt even
> with --force, or maybe it does but then runs an older copy of the exe,
> or something screwy like that. I need to look into that more.
>

RDMD Regression Filed:
https://d.puremagic.com/issues/show_bug.cgi?id=12149