The Right Approach to Exceptions
doob at me.com
Tue Feb 21 03:11:56 PST 2012
On 2012-02-21 03:34, Andrei Alexandrescu wrote:
> On 2/20/12 6:51 PM, H. S. Teoh wrote:
>> On Mon, Feb 20, 2012 at 06:19:32PM -0600, Andrei Alexandrescu wrote:
>>> On 2/20/12 5:46 PM, Nick Sabalausky wrote:
>>>> You've suggested adding "Variant[string] info" to Exception for the
>>>> sake of i18n. I think that's what he's referring to. You *could*
>>>> argue that's not technically i18n, but so far i18n seems to be the
>>>> only real use-case for it (although even that much has been disputed
>>>> in light of reflection).
>>> All formatting and rendering of the exception information is helped.
>>> And I think that's great because that's the most common activity one
>>> would do with exceptions.
>> Then, obviously, different development environments are leading to
>> vastly different conclusions, because I can't for the life of me imagine
>> that the most common activity you would do with an exception is to print
> Different strokes for different folks I'd say. I think I could claim a
> little authority on diversity. I've worked on an extremely diverse range
> of applications; in fact I've made a point to acquire broad specialization.
> In virtually all systems I've worked on, rendering meaningful error
> messages out of exception information has been a major concern, and in
> most of them the problem has been poorly addressed. It is very exciting
> to have an opportunity to improve on the state of affairs.
I think the correct way of handling this is provide enough information
in the exception so a message can be built where the exception is
caught. It might happen the you want to catch the same exception in
different parts of the code and build different messages.
More information about the Digitalmars-d