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
