Thread overview
override toString of Exception
Oct 20, 2012
David
Oct 20, 2012
Jacob Carlborg
Oct 21, 2012
David
Oct 21, 2012
Ali Çehreli
Oct 21, 2012
David
Oct 21, 2012
David
Oct 22, 2012
Ali Çehreli
October 20, 2012
class BraLaException : Exception {
    this(string s, string f=__FILE__, size_t l=__LINE__) {
        super(s, f, l);
    }

    override string toString() {
        return "bar";
    }
}


when throwing this exception, I still get the stacktrace and not "bar", is it possible to change that behaviour?
October 20, 2012
On 2012-10-20 18:42, David wrote:
> class BraLaException : Exception {
>      this(string s, string f=__FILE__, size_t l=__LINE__) {
>          super(s, f, l);
>      }
>
>      override string toString() {
>          return "bar";
>      }
> }
>
>
> when throwing this exception, I still get the stacktrace and not "bar",
> is it possible to change that behaviour?

Perhaps this function can help:

http://dlang.org/phobos/core_runtime.html#traceHandler

-- 
/Jacob Carlborg
October 21, 2012
>> when throwing this exception, I still get the stacktrace and not "bar",
>> is it possible to change that behaviour?
>
> Perhaps this function can help:
>
> http://dlang.org/phobos/core_runtime.html#traceHandler

Unfortunatly not, it expects a function which returns TraceInfo, but I simply wanna modify the resulting string (add escape sequences).

October 21, 2012
On 10/20/2012 09:42 AM, David wrote:
> class BraLaException : Exception {
> this(string s, string f=__FILE__, size_t l=__LINE__) {
> super(s, f, l);
> }
>
> override string toString() {
> return "bar";
> }
> }
>
>
> when throwing this exception, I still get the stacktrace and not "bar",
> is it possible to change that behaviour?

The backtrace is not printed if the exception is caught:

class MyException : Exception
{
    string s;

    this(string s, string f=__FILE__, size_t l=__LINE__) {
        super("bar", f, l);
        this.s = s;
    }

    override string toString() const
    {
        return s;
    }
}

void main()
{
    try {
        throw new MyException("bar");

    } catch (Exception e) {
        assert(e.toString() == "bar");
    }
}

This behavior makes sense to me because printing the backtrace should concern the application, not the exception itself. If the application does not want the backtrace printed, it can handle all of the exceptions.

Ali
October 21, 2012
> This behavior makes sense to me because printing the backtrace should
> concern the application, not the exception itself. If the application
> does not want the backtrace printed, it can handle all of the exceptions.
>
> Ali

I just want to add color to my exceptions and the easiest way is to override toString, that is not possible since, the printing-code in druntime doesn't call exception.toString, but reimplements it's default behaviour.

I "fixed" it:
https://github.com/D-Programming-Language/druntime/pull/331
October 21, 2012
Am 21.10.2012 22:46, schrieb David:>  > This behavior makes sense to me because printing the backtrace should
>  > concern the application, not the exception itself. If the application
>  > does not want the backtrace printed, it can handle all of the
> exceptions.
>  >
>  > Ali
>
> I just want to add color to my exceptions and the easiest way is to
> override toString, that is not possible since, the printing-code in
> druntime doesn't call exception.toString, but reimplements it's default
> behaviour.
>
> I "fixed" it:
> https://github.com/D-Programming-Language/druntime/pull/331

Well, it can be used to way more than only coloring the exception, you can also provide additional information etc. and I think it makes more sense, why is there a toString implemented if it isn't used.
October 22, 2012
On 10/21/2012 01:51 PM, David wrote:
> Am 21.10.2012 22:46, schrieb David:> > This behavior makes sense to me
> because printing the backtrace should
>  > > concern the application, not the exception itself. If the application
>  > > does not want the backtrace printed, it can handle all of the
>  > exceptions.
>  > >
>  > > Ali
>  >
>  > I just want to add color to my exceptions and the easiest way is to
>  > override toString, that is not possible since, the printing-code in
>  > druntime doesn't call exception.toString, but reimplements it's default
>  > behaviour.
>  >
>  > I "fixed" it:
>  > https://github.com/D-Programming-Language/druntime/pull/331
>
> Well, it can be used to way more than only coloring the exception, you
> can also provide additional information etc. and I think it makes more
> sense, why is there a toString implemented if it isn't used.

I don't see that: toString() does get used when the exception object appears in a string context. That part works.

What you are asking is why not the runtime calls only toString() of the object. The backtrace information is helpful as well, so a special exception type should not take away that information from the whole application. What does the little exception know about the application that it decides that the backtrace not be produced? I think the exception type is the wrong place to make that decision.

If it is important for the application that the backtrace is not printed, it can simply catch all exceptions in main. Backtrace is printed only for unhandled exceptions.

Ali