• Dmitry Olshansky (18/18) Jun 14 2014 Recalling the previous discussion of throwing exception being costly, I
• Element 126 (5/21) Jun 14 2014 ---
• Dmitry Olshansky (10/38) Jun 15 2014 No, normal exceptions print just fine. e.g.
• Jacob Carlborg (10/17) Jun 15 2014 Is this because "writeln" tries to use the one without parameters? If

Dmitry Olshansky <dmitry.olsh gmail.com> writes:

Recalling the previous discussion of throwing exception being costly, I 
thought the idiom of "pay as you go" is worth incorporating into the 
standard library.

In brief:

throw exception("CPU temperature is below", 2.5, "K");
vs
throw new Exception(text("CPU temperature is below", 2.5, "K"));
or:
enforce(false, text("CPU temperature is below", 2.5, "K"));

The benefit that the latter will only construct string if printing is 
indeed requested.

Proof of concept:
https://gist.github.com/DmitryOlshansky/59ec5953874bc1985ac5

The problem with it is that for some reason writeln of exception won't 
compile while thrown exception is printed just fine by the trace handler.

Thoughts?

-- 
Dmitry Olshansky

Element 126 <dlang.element126 gmail.com> writes:

On 06/14/2014 09:04 PM, Dmitry Olshansky wrote:
 Recalling the previous discussion of throwing exception being costly, I
 thought the idiom of "pay as you go" is worth incorporating into the
 standard library.

 In brief:

 throw exception("CPU temperature is below", 2.5, "K");
 vs
 throw new Exception(text("CPU temperature is below", 2.5, "K"));
 or:
 enforce(false, text("CPU temperature is below", 2.5, "K"));

 The benefit that the latter will only construct string if printing is
 indeed requested.

 Proof of concept:
 https://gist.github.com/DmitryOlshansky/59ec5953874bc1985ac5

 The problem with it is that for some reason writeln of exception won't
 compile while thrown exception is printed just fine by the trace handler.

 Thoughts?

---
writeln(myException.info);
---

Is it what you are looking for ?

Dmitry Olshansky <dmitry.olsh gmail.com> writes:

15-Jun-2014 02:03, Element 126 пишет:
 On 06/14/2014 09:04 PM, Dmitry Olshansky wrote:
 Recalling the previous discussion of throwing exception being costly, I
 thought the idiom of "pay as you go" is worth incorporating into the
 standard library.

 In brief:

 throw exception("CPU temperature is below", 2.5, "K");
 vs
 throw new Exception(text("CPU temperature is below", 2.5, "K"));
 or:
 enforce(false, text("CPU temperature is below", 2.5, "K"));

 The benefit that the latter will only construct string if printing is
 indeed requested.

 Proof of concept:
 https://gist.github.com/DmitryOlshansky/59ec5953874bc1985ac5

 The problem with it is that for some reason writeln of exception won't
 compile while thrown exception is printed just fine by the trace handler.

 Thoughts?

 ---
 writeln(myException.info);
 ---

 Is it what you are looking for ?

No, normal exceptions print just fine. e.g.
writeln(new Exception("abc"));
I'm wondering what's wrong the one I defined, the error message seems to 
indicate that it doesn't have toString. It's wrong as there is one 
derived from Exception.

Workaround was to use
alias toString = Base.toString;


-- 
Dmitry Olshansky

Jacob Carlborg <doob me.com> writes:

On 2014-06-15 11:40, Dmitry Olshansky wrote:

 No, normal exceptions print just fine. e.g.
 writeln(new Exception("abc"));
 I'm wondering what's wrong the one I defined, the error message seems to
 indicate that it doesn't have toString. It's wrong as there is one
 derived from Exception.

 Workaround was to use
 alias toString = Base.toString;

Is this because "writeln" tries to use the one without parameters? If 
you override one method, which as overloads, you need to override all 
overloads or bring them into the same overload set with an alias, as 
you've done above.

A base class and subclass have different overload sets [1].

[1] http://dlang.org/hijack.html search for "Derived Class Member 
Function Hijacking".

-- 
/Jacob Carlborg