"Andrei Alexandrescu" <[email protected]> wrote in message news:[email protected]... > On 2/19/12 1:19 PM, Nick Sabalausky wrote: >> That wouldn't be as useful. What the catcher is typically interested in >> is >> *what* happened, not *where* it happened. > > But module organization is partitioned by functional areas. > >> For example, if I want to do something upon a network error, minimum 99 >> times out of 100 I don't give a shit if it came from libNetworkFoo or >> libNetworkBar, and I don't *want* to care. What I care is whether or not >> there was a "network" error and possibly what *conceptual* type of >> network >> error. > > Then it wouldn't help if each defined its own hierarchy. >
Right, and yet that's exactly what your suggestion of tying exceptions to modules would imply. >> Furthurmore, what if I change some implementation detail to use a >> different >> module? Then I have to go changing all my catch blocks even though it's >> conceptually the same fucking error handled the same way. > > That is an issue regardless. Occasional exception translation is a fact of > life. > You're suggestion exacerbates the problem for no user benefit. This isn't the first time you've tried to push a negligably-time-saving scheme into Phobos at the expense of user code. > That's why PackageException!"tango.io" inherits PackageException!"tango". > That's all automatic. Essentially there's 1:1 correspondence between > package/module hierarchy and exception hierarchy. > But there *isn't* a 1:1 correspondence. A "file not found" is damn "file not found" no matter what lib you're using: phobos, tango, fooBarFileLib, what-the-hell-ever. You're "1:1" pretends that a non-existent file is somehow different from one lib to another. >> As far as "when to add or not add an exception class", it's perfectly >> reasonable to err on the side of too many: If there's an unnecessary >> class, >> you can just ignore it. Problem solved. If there's a missing exception >> class, you're shit out of luck. Case closed. > > I disagree that having too many exception types comes at no cost. > Jesus christ. You pull out the pedantic "that's not a perfectly-stated argument" whacking stick at every opportunity, and yet you yourself put forth arguments like "I disagree"? What the fuck? >> I can't shake the feeling that we're desperately trying to reinvent the >> wheel here. The round wheel is solid technology with a proven track >> record, >> we don't need to waste time evaluating all these square and oval wheels >> just >> for the fuck of it. > > The wheel is not round. We just got used to thinking it is. Exceptions are > wanting and it's possible and desirable to improve them. > They're wanting? What's the problem with them? I see no problem, and I haven't seen you state any real problem.
