The Right Approach to Exceptions
Jonathan M Davis
jmdavisProg at gmx.com
Mon Feb 20 15:49:40 PST 2012
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
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
More information about the Digitalmars-d