[phobos] Printing exceptions

[Andrei Alexandrescu]

Sounds great.

Andrei

On 04/07/2010 03:01 PM, Steve Schveighoffer wrote:
> toString should be final, it should do exactly what Sean is doing, return file:line: msg, and I would say a stack trace as well.
>
> msg should be a virtual property, and that's where someone can affect both toString and the runtime printout.
>
> So essentially, exactly what Andrei said, but s/toStringImpl/msg/
>
>  From Microsoft's Exception class (always good to look at what other languages do):
>
> "ToString returns a representation of the current exception that is intended to
> be understood by humans. Where the exception contains culture-sensitive
> data, the string representation returned by ToString is required to take into account the current system culture. Although
> there are no exact requirements for the format of the returned string,
> it should attempt to reflect the value of the object as perceived by
> the user.
> The default implementation of ToString obtains the name of the class that threw the current exception, the message, the result of calling ToString on the inner exception, and the result of calling Environment.StackTrace. If any of these members is Nothing, its value is not included in the returned string.
> If
> there is no error message or if it is an empty string (""), then no
> error message is returned. The name of the inner exception and the
> stack trace are returned only if they are not Nothing.
> This method overrides Object.ToString."
> -Steve
>
>
>
> ----- Original Message ----
>> From: Andrei Alexandrescu<andrei at erdani.com>
>> To: Discuss the phobos library for D<phobos at puremagic.com>
>> Sent: Wed, April 7, 2010 2:39:20 PM
>> Subject: Re: [phobos] Printing exceptions
>>
>> This seems to be an instance of the problem NVI is supposed to solve: the
>> interface for users should not be the same as the interface for
>> customization.
>
> In an NVI approach, toString would be final and there
>> would be an overridable toStringImpl that users can tweak. Then toString would
>> call toStringImpl and decorate it with stack trace info etc.
>
> Anyway,
>> since toString is already overridable, I suggest you just add a detailedReason()
>> function that formats and returns a string including whatever toString()
>> returns, then also file and line info and stack trace. If an exception leaves
>> main(), print detailedReason(), not toString().
>
>
> Andrei
>
> On
>> 04/07/2010 01:09 PM, Sean Kelly wrote:
>> On Apr 7, 2010, at 8:53 AM,
>> Robert Clipsham wrote:
>>
>>> On 07/04/10 16:29, Sean Kelly
>> wrote:
>>>> The runtime can do one of two things: print exceptions
>> according to a standard format and inject the msg field in the proper place or
>> it can call toString.  Which should be done?  I prefer the former
>> because it makes for a standard presentation and doesn't risk allocating memory
>> needlessly, but I can see how people might do fancy stuff in toString that they
>> expect to be used instead.  This came up because I'm adding a default stack
>> trace handler, and the current behavior prints the stack trace twice, so
>> something needs to change.
>>>
>>> I think the better option
>> would be to print them in the standard format, at least by default. You could
>> always include several trace handlers to allow the user to effortlessly pick the
>> handler they want, rather than everyone implementing their own for when they
>> want to use toString.
>>
>> My worry is that someone will do
>> something fancy in their toString override and expect it to print if the
>> exception escapes main().  The default behavior is basically to print
>> "file:line: msg" which sidesteps any custom code in toString completely.
>> The current code is actually a bit weird and uses the custom format if the file
>> string is non-null and calls toString otherwise, but that seems like it's even
>> less predictable than simply always using a custom or the toString format.
>> I also don't see any easy way to provide a default formatter, since ranges are
>> defined in Phobos and not druntime (ie. you couldn't have
>> Exception.outputTo(Range)).
>>
>> I've personally never liked
>> toString, but since it exists it seems like the only reasonable thing to do is
>> always call it.
>> _______________________________________________
>>
>> phobos mailing list
>>
>> href="mailto:phobos at puremagic.com">phobos at puremagic.com
>>
>> http://lists.puremagic.com/mailman/listinfo/phobos
> _______________________________________________
> phobos
>> mailing list
>
>> href="mailto:phobos at puremagic.com">phobos at puremagic.com
>
>> href="http://lists.puremagic.com/mailman/listinfo/phobos" target=_blank
>>> http://lists.puremagic.com/mailman/listinfo/phobos
>
>
>
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos