The Right Approach to Exceptions

[Jonathan M Davis]

On Monday, February 20, 2012 17:22:13 Andrei Alexandrescu wrote:
> On 2/20/12 4:25 PM, Jonathan M Davis wrote:
> > In my experience, the type is very much tied to the context.
> 
> I thought you said the type is tied to "what happened, not where it
> happened", which is the polar opposite of the above.

A particular exception type says that a particular thing happened, and that's 
almost always tied to a particular set of information. If you have a 
SocketException, then there's always an IP and port involved no matter what 
function it's thrown from and _that_ context doesn't change. Certain types of 
data almost always go with certain problems and therefore certain exception 
types.

If you mean context in terms of where it's being thrown from, then no, that's 
not generally connected at all.

> Whenever you put data in member variables you set yourself up for code
> bloat. Do you agree?

Not really. You put them in there if you need them. And shifting them into an 
AA of Variants doesn't help any. It just reduces the size of the class itself. 
You still have to set them, and code that uses them still has to reference 
them. You also end up using more memory.

And when it comes to exceptions, having a few more pieces of data that you 
don't always need but might be useful doesn't really cost you much, because 
you don't construct them often, and you're not going to have very many 
instantiated at once. They almost always have a very short lifespan. I'd be 
far more worried about restricting the number of member variables in types 
which are going to actually be commonly instantiated and potentially have many 
of them in memory. We obviously shouldn't go to town adding everything and the 
kitchen sink to every exception type, but having a few extra member variables 
on them doesn't seem like a big deal to me.

- Jonathan M Davis