The Right Approach to Exceptions

Jacob Carlborg 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
>> it.
>
> 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.
>
>
> Andrei

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.

-- 
/Jacob Carlborg


More information about the Digitalmars-d mailing list