The CSS functionality that works the same between the various recent browsers is sufficient to code up good, modern looking websites. There is no need to code in browser dependencies.
While each browser does support CSS, and even some HTML a bit differently, what functionality seem to be universal across all of the major modern players? Can you design a sharp looking website with such features, without resorting to browser-specific code? If so, how?
You read the W3 specs and code to them. Then, you test with several modern browsers and remove whatever features still cause undesirable behavior.
Note that CSS itself has lots of limitations and seems to leave a number of layout decisions up to the implementation. So, you can't realize every flight of fancy, you will have to choose a design that's a compromise between what is possible and what your graphic artists want.
Note also that "sharp looking" and "usable" are often in conflict to some degree when it comes to web sites. In most cases, usability is more important.
Of course it is! A common package notation allows dependencies between software components to be detected precisely and automatically.
But we don't have a common package "notation"--that's the problem. Creating a new "notation" or a new format or a new tool isn't going to change that.
It's only a step from there to have dependencies resolved automatically as well.
No, it's not. For anything like a UNIX system, there is no way in hell that you can determine and/or resolve dependencies reliably.
I've also noticed that relocation is often not done properly in open source packages.
Relocation is done quite properly in most open source packages: at build time, through autoconf.
I suspect this may be because many open source developers are not used to installing software at complex sites where different administrative groups maintain different sets of software at different points on different servers.
You suspect wrong. Some of the biggest and most complex installations are handled by open source software and open source developers.
Over the years, I've noticed that autoconf handles this situation very cleanly. It's the people building binary packages that seem to overlook the need for relocation.
Binary packages are not "relocatable" in general (meaning, you can't change paths around arbitrarily). And they won't become relocatable because it would be a PITA and because a large fractions wouldn't do it anyway.
If you want a solution to that problem, you need functionality like that found in Plan 9, either at the C library level or, better, in the Linux kernel. But then people like you, you know self-proclaimed "real world users", self-proclaimed people "who install and maintain many different sets of software" complain that they don't want such "academic" solutions, which they don't understand, yet actually desparately need.
People get so hung up on the package format. It really isn't about the package format, it's about the people and organization behind the packages and whether they produce a consistent distribution. A "better" package format or a better installer isn't going to help you when a piece of software expects libraries to be there that just aren't available, or when an install script assumes functionality you don't have.
You'll probably see proxy DNS servers and DNS libraries that first look up the DNS record, then try to connect to the web server on the address they find, and finally return a corrected DNS record depending on whether the web server is Verisign's or not.
As a result, Verisign will be serving a lot of useless pages and eating up a lot of extra bandwidth. Eventually, that's going to cost them. Let's hope it will cost them enough that they will stop this nonsense.
If you really want to fight this, tone down some of the passion and write to ICANN with legitimate concerns about the service and its effects.
It would be bad even if it had no effects. Verisign is tasked with running the domain name system, not changing it.
But, in fact, it does have an effect, and a big one: it precludes an efficient market in the kinds of functionality Verisign is adding. They are using the trust that has been placed in them to create a business for themselves that few others can compete in. The proper way in which to do this is to create a standard by which users themselves can choose what to do when a page wasn't found.
Crying foul about slimy business practices with no supporting evidence
What more evidence do you want than the actions they have taken in plain sight? Unilaterally changing the behavior of the domain name system for corporate gain is, by itself, a slimy business practice.
You can find out whether personal information about you is available accidentally by searching for your name and a piece of your sensitive information on Google, say, your name and the last four digits of your SSN, the last four digits of a credit card number, parts of your phone number, or your street address. Leaked personal information would have to contain both your name and that other information. Chances are that you will retrieve only a few documents, which you can quickly review.
Keep in mind, however, that Google queries are not encrypted and are not guaranteed to be private or secure, so, for your search, don't use the full SSN or anything else that shouldn't be disclosed.
"The scariest thing is that this could be happening to the government and they may never know it was happening," Long said.
This isn't "happening to the government", as if the government is some innocent victim. Rather, "the government screwed up big time". Likewise, if some company has sensitive personal information lying around on a public web server, the company is at fault and should be liable.
I don't know if this is the norm, but I'm contracted for a specific number of hours per week.
Not if you are an "exempt" employee. You can tell if you get paid overtime: if you aren't, you are exempt. If you are exempt, you are indeed not paid for a specific number of hours.
Alternatively, if stuff I do "in my own time" at 1am could be claimed by the company, perhaps this means I don't have to bother coming into the office next day, since I've been hard at work all night at home..?
Yes, that's indeed the general idea: if you did something even remotely related to the company's business at 1am, then you were working for them at that time. However, if the stuff you did at 1am didn't contribute to their bottom line, it was wasted effort. And whether you need to come into the office the next day depends on whether you are needed, not on your total number of hours worked--remember, you are "exempt" from overtime.
However, I might make the caveat that I have had, as another poster states, ongoing projects that existed prior to my employment exempted where they had no bearing on the employer's area of operations. Further, I have had entire areas of endeavor exempted as well, specifically, my writing unless it relates to products produced by the company.
Right, and that's all I was saying: many employers will be happy to exempt specific areas, as long as there is no conflict of interest. In fact, many employers already have provisions for just that in their contracts.
The existence of dark matter has also been inferred from other observations (see above link), but even if that observation doesn't hold up, the odd behavior of galaxies still remains.
First of all, this has nothing to do with NDAs; the NDA is independent of whether you can work on something else outside your job. More importantly, my point is that this isn't up to the company: for certain classes of employees, there simply doesn't exist a concept of "on your own time". It doesn't matter how nice the company may try to be about it, it just doesn't make sense.
What they can do is give you an exemption based on the specific project. And many companies will do that as long as there is no conflict of interest. If there is, they will and they should, and you should make a choice.
these things are changeable and you do NOT want to work there if they are not.
Sorry, but that's bad advice. There are certain things that are changeable and certain things that aren't.
If you work in tech support or repair, sure, then there may be a concept of "on your own time" and an employer may not even be able to make claims to anything outside your working hours.
But if you are VP of Engineering at Oracle, you can't work as a VP of Engineering at Microsoft's database division, whether it's "on your own time" or not.
In fact, above a certain level of skill, pay, and/or education, both the law and business practices just stops recognizing a concept of "on your own time". (You'll know when you reach that level;-)
Do you really think this is the first time this has happened? Many companies in the high tech business have provisions in their contracts for dealing with "outside interests" and other intellectual property because it comes up all the time. You don't have to go in and do surgery on their contract language, you simply indicate on the contract (usually, there is a space provided for it) that you have outside interests and attach a letter explaining them and how you are planning to pursue them. You have that signed by the company during hiring.
This sort of thing isn't rocket science. Contracts are meant to communicate expectations among people in order to avoid misunderstandings. If your employer gives you a contract that is so tricky that you can't decipher it, you should perhaps consider not working for them at all.
But if it does make you happy, you can try to find a good lawyer; frankly, in my experience, that's harder than finding a good employer.
I would like to change the wording to only include those creations, inventions and other Intellectual Property that is the direct result of work performed for the company, involved use of company property, and/or was created or invented during paid hours spent working for the company.
For many kinds of software and management jobs, there is really no such concept as "during paid hours". So, it doesn't make a lot of sense to talk about what you do outside those hours. And, from a purely practical point of view, the company just won't agree to it.
What you can do is ask for is a specific exemption for that particular project. You and your company would have to sit down and specify carefully what areas you can work in.
If your outside work overlaps substantially with your new employer's business then you can forget it. They aren't going to agree to letting you work outside in the same area you work for them (and they would be fools if they did).
Isn't an umbrella bad for the enviornment because it keeps the water from getting to where it would have fallen? Nah..
It's not an environmental issue, it's a liability issue. If you get me all wet by holding your umbrella wrong, you are liable for the damage you cause. The same applies here: if you damage someone else's property by messing with the weather, you bet you are going to be held responsible for that.
Just think of this as a big umbrella!:)
Yup. And just like with a big umbrella, you are responsible.
This is "cat-ions", i.e., ionized cats, not "cations". If you shoot millions of ionized cats into the stratosphere, it does prevent hail storms from forming (but you do have to contend with falling cats).
Nothing like a little begging the question fallacy to get your day started. (Hint: there is no demonstrated evidence that being anywhere near a high power line is harmful at all. Witness the astounding lack of corpses of all varieties along the millions of miles of high power lines crossing the United States.)
Well, golly, by your argument cigarettes cannot be killing anyone either, then. I mean, when was the last time you saw a corpse with a lit cigarette in his mouth?
Is there any evidence that being near high power lines is harmful? I have no idea. Cancer is so frequent that if power lines cause thousands of people to get cancer, it would probably be very hard to detect. And, since such simple matters of civilization seem to elude you, people who get cancer generally die in hospitals.
So, because such effects are hard and costly to detect through population studies, people look for causal relationships and mechanisms. You know, the kinds of relationships and mechanisms apologists for businesses, Republicans, and power companies always demand.
It's always the others that are the "useless meeting wack jobs", isn't it.
Fact is, anybody can become an annoying and unproductive participant in meetings when the circumstances are wrong. And one person's useless verbiage can be a productive contribution to someone else, while your erudite locutions and insightful analysis may just be considered "hot air" by everybody else.
So, worry about your own contributions first, don't try to second-guess other people.
Re:I don't think so. Here's why.
on
How C# Was Made
·
· Score: 1
I can't agree with you on that. I think you have seen code which uses exceptions incorrectly if you have reached this conclusion.
Yes, the fact that a lot of exception handling in Java libraries is broken is one indication that exception declarations are having the opposite effect from what they are intended to achieve.
In general, you shouldn't be propagating implementation-specific exceptions to your callers unless they are guaranteed to be essentially indistinguishable "failure" reports
The problem is not with that "in general" statement (one can argue about it, but it's a question of style), it's with trying to enforce it through mandatory exception declarations. Mandatory exception declarations may help with that particular style of exception handling, but they break other, widely-accepted styles of exception handling.
C++ also has exception declarations. C++ lets you guarantee to a caller that an interface doesn't throw anything you don't expect it to throw, just like you want it to. But C++'s exception declaration system doesn't break other code. Java's designers just got it wrong.
Re:What did they miss about checked exceptions
on
How C# Was Made
·
· Score: 1
Object oriented programming is all about exposing clean programming interfaces,
Sure.
and what exceptions your objects' methods throw are as much a part of those interfaces as their parameter lists and return types.
Yes, that's what exception declarations are trying to achieve, but they are trying to achieve the unachievable. The whole point behind exceptions is that they are non-local exits.
When I call a method called getWeatherForecast(), I want it to return me the weather forecast, or throw me a WeatherNotAvailableException. I don't want it to sometimes throw a DbException because it had to go and talk to a database, or sometimes an IOException because it's reading from a cached file, or sometimes throw a NetException because it's talking through a socket, or sometimes throw a SoapException because it's trying to reach a web service.
Yes, and in that case, getWeatherForcast() might catch some exceptions and re-throw a WeatherNotAvailableException--nothing is keeping you from that in languages without exception declarations. The problem is that you erroneously assume that all exception handling in OO systems can be structured that way, and it can't.
Note that Java's exception declaration system makes no guarantees anyway, since you can still get unexpected errors and exceptions from any method you call.
Re:your entire view is wrong
on
How C# Was Made
·
· Score: 1
Odd that you talk about OO programming as involving stacks of method calls... that sounds more like procedural, function-pointer-led thinking than OO, interface-led thinking to me.
Exception handling does involve stacks of procedure calls. That's precisely why exposing it in an OOL is a bad idea: it forces programmers to encode procedural aspects of their object-oriented designs in exception declarations. Worse, it can't be done correctly in general.
I don't see how you can end up in the situation you described without the method Q having some interest in the behavior of R...
Easy. Consider the Comparator class. Let's say the comparison involves operations that can throw an IOException. You will notice that the Comparator methods don't declare any exceptions, and why should they? The "sort" method isn't interested in anything that can go wrong with Comparator. Whether you wrap the exception or not, it just has to get propagated upwards anyway.
What right does R() have to assume that the code anywhere above it in the callstack comes from the same library? Why can't it have been code in a completely different library that instantiated C, and called Q()?
Well, in that case, you have a bug. Unfortunately, it's a bug that cannot be avoided by exception declarations. The motivation behind exception declarations is laudable, but they just don't achieve their goals--they only cause people to add a lot more code that, in the end, is no safer than what they started with.
Slashdot Mirror
The laptop style fits the person, and everybody else at the meeting sees right away who they are dealing with. 'Nuff said.
The CSS functionality that works the same between the various recent browsers is sufficient to code up good, modern looking websites. There is no need to code in browser dependencies.
While each browser does support CSS, and even some HTML a bit differently, what functionality seem to be universal across all of the major modern players? Can you design a sharp looking website with such features, without resorting to browser-specific code? If so, how?
You read the W3 specs and code to them. Then, you test with several modern browsers and remove whatever features still cause undesirable behavior.
Note that CSS itself has lots of limitations and seems to leave a number of layout decisions up to the implementation. So, you can't realize every flight of fancy, you will have to choose a design that's a compromise between what is possible and what your graphic artists want.
Note also that "sharp looking" and "usable" are often in conflict to some degree when it comes to web sites. In most cases, usability is more important.
Of course it is! A common package notation allows dependencies between software components to be detected precisely and automatically.
But we don't have a common package "notation"--that's the problem. Creating a new "notation" or a new format or a new tool isn't going to change that.
It's only a step from there to have dependencies resolved automatically as well.
No, it's not. For anything like a UNIX system, there is no way in hell that you can determine and/or resolve dependencies reliably.
I've also noticed that relocation is often not done properly in open source packages.
Relocation is done quite properly in most open source packages: at build time, through autoconf.
I suspect this may be because many open source developers are not used to installing software at complex sites where different administrative groups maintain different sets of software at different points on different servers.
You suspect wrong. Some of the biggest and most complex installations are handled by open source software and open source developers.
Over the years, I've noticed that autoconf handles this situation very cleanly. It's the people building binary packages that seem to overlook the need for relocation.
Binary packages are not "relocatable" in general (meaning, you can't change paths around arbitrarily). And they won't become relocatable because it would be a PITA and because a large fractions wouldn't do it anyway.
If you want a solution to that problem, you need functionality like that found in Plan 9, either at the C library level or, better, in the Linux kernel. But then people like you, you know self-proclaimed "real world users", self-proclaimed people "who install and maintain many different sets of software" complain that they don't want such "academic" solutions, which they don't understand, yet actually desparately need.
People get so hung up on the package format. It really isn't about the package format, it's about the people and organization behind the packages and whether they produce a consistent distribution. A "better" package format or a better installer isn't going to help you when a piece of software expects libraries to be there that just aren't available, or when an install script assumes functionality you don't have.
You'll probably see proxy DNS servers and DNS libraries that first look up the DNS record, then try to connect to the web server on the address they find, and finally return a corrected DNS record depending on whether the web server is Verisign's or not.
As a result, Verisign will be serving a lot of useless pages and eating up a lot of extra bandwidth. Eventually, that's going to cost them. Let's hope it will cost them enough that they will stop this nonsense.
If you really want to fight this, tone down some of the passion and write to ICANN with legitimate concerns about the service and its effects.
It would be bad even if it had no effects. Verisign is tasked with running the domain name system, not changing it.
But, in fact, it does have an effect, and a big one: it precludes an efficient market in the kinds of functionality Verisign is adding. They are using the trust that has been placed in them to create a business for themselves that few others can compete in. The proper way in which to do this is to create a standard by which users themselves can choose what to do when a page wasn't found.
Crying foul about slimy business practices with no supporting evidence
What more evidence do you want than the actions they have taken in plain sight? Unilaterally changing the behavior of the domain name system for corporate gain is, by itself, a slimy business practice.
Actually, the more common (near-) surface transport that people propose to use with non-geostationary space elevators is airplanes.
You can find out whether personal information about you is available accidentally by searching for your name and a piece of your sensitive information on Google, say, your name and the last four digits of your SSN, the last four digits of a credit card number, parts of your phone number, or your street address. Leaked personal information would have to contain both your name and that other information. Chances are that you will retrieve only a few documents, which you can quickly review.
Keep in mind, however, that Google queries are not encrypted and are not guaranteed to be private or secure, so, for your search, don't use the full SSN or anything else that shouldn't be disclosed.
"The scariest thing is that this could be happening to the government and they may never know it was happening," Long said.
This isn't "happening to the government", as if the government is some innocent victim. Rather, "the government screwed up big time". Likewise, if some company has sensitive personal information lying around on a public web server, the company is at fault and should be liable.
Let's not make victims out of perpetrators.
I don't know if this is the norm, but I'm contracted for a specific number of hours per week.
Not if you are an "exempt" employee. You can tell if you get paid overtime: if you aren't, you are exempt. If you are exempt, you are indeed not paid for a specific number of hours.
Alternatively, if stuff I do "in my own time" at 1am could be claimed by the company, perhaps this means I don't have to bother coming into the office next day, since I've been hard at work all night at home..?
Yes, that's indeed the general idea: if you did something even remotely related to the company's business at 1am, then you were working for them at that time. However, if the stuff you did at 1am didn't contribute to their bottom line, it was wasted effort. And whether you need to come into the office the next day depends on whether you are needed, not on your total number of hours worked--remember, you are "exempt" from overtime.
Yes, but at that point Ask Slashdot might not be a terribly useful source of information about similar people's experiences.
Many Slashdot readers have reached that level as soon as they accept a software development position.
However, I might make the caveat that I have had, as another poster states, ongoing projects that existed prior to my employment exempted where they had no bearing on the employer's area of operations. Further, I have had entire areas of endeavor exempted as well, specifically, my writing unless it relates to products produced by the company.
Right, and that's all I was saying: many employers will be happy to exempt specific areas, as long as there is no conflict of interest. In fact, many employers already have provisions for just that in their contracts.
Dark matter was postulated because galaxies spin at the wrong rate for the amount of observable matter they contain. That's not some obscure thing having to do with background radiation or age of the universe, it's a pretty concrete problem that can't be easily be explained away by reinterpreting measurements.
The existence of dark matter has also been inferred from other observations (see above link), but even if that observation doesn't hold up, the odd behavior of galaxies still remains.
No, you are missing the point.
First of all, this has nothing to do with NDAs; the NDA is independent of whether you can work on something else outside your job. More importantly, my point is that this isn't up to the company: for certain classes of employees, there simply doesn't exist a concept of "on your own time". It doesn't matter how nice the company may try to be about it, it just doesn't make sense.
What they can do is give you an exemption based on the specific project. And many companies will do that as long as there is no conflict of interest. If there is, they will and they should, and you should make a choice.
these things are changeable and you do NOT want to work there if they are not.
;-)
Sorry, but that's bad advice. There are certain things that are changeable and certain things that aren't.
If you work in tech support or repair, sure, then there may be a concept of "on your own time" and an employer may not even be able to make claims to anything outside your working hours.
But if you are VP of Engineering at Oracle, you can't work as a VP of Engineering at Microsoft's database division, whether it's "on your own time" or not.
In fact, above a certain level of skill, pay, and/or education, both the law and business practices just stops recognizing a concept of "on your own time". (You'll know when you reach that level
Do you really think this is the first time this has happened? Many companies in the high tech business have provisions in their contracts for dealing with "outside interests" and other intellectual property because it comes up all the time. You don't have to go in and do surgery on their contract language, you simply indicate on the contract (usually, there is a space provided for it) that you have outside interests and attach a letter explaining them and how you are planning to pursue them. You have that signed by the company during hiring.
This sort of thing isn't rocket science. Contracts are meant to communicate expectations among people in order to avoid misunderstandings. If your employer gives you a contract that is so tricky that you can't decipher it, you should perhaps consider not working for them at all.
But if it does make you happy, you can try to find a good lawyer; frankly, in my experience, that's harder than finding a good employer.
I would like to change the wording to only include those creations, inventions and other Intellectual Property that is the direct result of work performed for the company, involved use of company property, and/or was created or invented during paid hours spent working for the company.
For many kinds of software and management jobs, there is really no such concept as "during paid hours". So, it doesn't make a lot of sense to talk about what you do outside those hours. And, from a purely practical point of view, the company just won't agree to it.
What you can do is ask for is a specific exemption for that particular project. You and your company would have to sit down and specify carefully what areas you can work in.
If your outside work overlaps substantially with your new employer's business then you can forget it. They aren't going to agree to letting you work outside in the same area you work for them (and they would be fools if they did).
If they are so close in orbit to the orbit of a space elevator, why not just use one of the moons as a base for the space elevator?
Isn't an umbrella bad for the enviornment because it keeps the water from getting to where it would have fallen? Nah..
:)
It's not an environmental issue, it's a liability issue. If you get me all wet by holding your umbrella wrong, you are liable for the damage you cause. The same applies here: if you damage someone else's property by messing with the weather, you bet you are going to be held responsible for that.
Just think of this as a big umbrella!
Yup. And just like with a big umbrella, you are responsible.
This is "cat-ions", i.e., ionized cats, not "cations". If you shoot millions of ionized cats into the stratosphere, it does prevent hail storms from forming (but you do have to contend with falling cats).
Nothing like a little begging the question fallacy to get your day started. (Hint: there is no demonstrated evidence that being anywhere near a high power line is harmful at all. Witness the astounding lack of corpses of all varieties along the millions of miles of high power lines crossing the United States.)
Well, golly, by your argument cigarettes cannot be killing anyone either, then. I mean, when was the last time you saw a corpse with a lit cigarette in his mouth?
Is there any evidence that being near high power lines is harmful? I have no idea. Cancer is so frequent that if power lines cause thousands of people to get cancer, it would probably be very hard to detect. And, since such simple matters of civilization seem to elude you, people who get cancer generally die in hospitals.
So, because such effects are hard and costly to detect through population studies, people look for causal relationships and mechanisms. You know, the kinds of relationships and mechanisms apologists for businesses, Republicans, and power companies always demand.
It's always the others that are the "useless meeting wack jobs", isn't it.
Fact is, anybody can become an annoying and unproductive participant in meetings when the circumstances are wrong. And one person's useless verbiage can be a productive contribution to someone else, while your erudite locutions and insightful analysis may just be considered "hot air" by everybody else.
So, worry about your own contributions first, don't try to second-guess other people.
I can't agree with you on that. I think you have seen code which uses exceptions incorrectly if you have reached this conclusion.
Yes, the fact that a lot of exception handling in Java libraries is broken is one indication that exception declarations are having the opposite effect from what they are intended to achieve.
In general, you shouldn't be propagating implementation-specific exceptions to your callers unless they are guaranteed to be essentially indistinguishable "failure" reports
The problem is not with that "in general" statement (one can argue about it, but it's a question of style), it's with trying to enforce it through mandatory exception declarations. Mandatory exception declarations may help with that particular style of exception handling, but they break other, widely-accepted styles of exception handling.
C++ also has exception declarations. C++ lets you guarantee to a caller that an interface doesn't throw anything you don't expect it to throw, just like you want it to. But C++'s exception declaration system doesn't break other code. Java's designers just got it wrong.
Object oriented programming is all about exposing clean programming interfaces,
Sure.
and what exceptions your objects' methods throw are as much a part of those interfaces as their parameter lists and return types.
Yes, that's what exception declarations are trying to achieve, but they are trying to achieve the unachievable. The whole point behind exceptions is that they are non-local exits.
When I call a method called getWeatherForecast(), I want it to return me the weather forecast, or throw me a WeatherNotAvailableException. I don't want it to sometimes throw a DbException because it had to go and talk to a database, or sometimes an IOException because it's reading from a cached file, or sometimes throw a NetException because it's talking through a socket, or sometimes throw a SoapException because it's trying to reach a web service.
Yes, and in that case, getWeatherForcast() might catch some exceptions and re-throw a WeatherNotAvailableException--nothing is keeping you from that in languages without exception declarations. The problem is that you erroneously assume that all exception handling in OO systems can be structured that way, and it can't.
Note that Java's exception declaration system makes no guarantees anyway, since you can still get unexpected errors and exceptions from any method you call.
Odd that you talk about OO programming as involving stacks of method calls... that sounds more like procedural, function-pointer-led thinking than OO, interface-led thinking to me.
Exception handling does involve stacks of procedure calls. That's precisely why exposing it in an OOL is a bad idea: it forces programmers to encode procedural aspects of their object-oriented designs in exception declarations. Worse, it can't be done correctly in general.
I don't see how you can end up in the situation you described without the method Q having some interest in the behavior of R...
Easy. Consider the Comparator class. Let's say the comparison involves operations that can throw an IOException. You will notice that the Comparator methods don't declare any exceptions, and why should they? The "sort" method isn't interested in anything that can go wrong with Comparator. Whether you wrap the exception or not, it just has to get propagated upwards anyway.
What right does R() have to assume that the code anywhere above it in the callstack comes from the same library? Why can't it have been code in a completely different library that instantiated C, and called Q()?
Well, in that case, you have a bug. Unfortunately, it's a bug that cannot be avoided by exception declarations. The motivation behind exception declarations is laudable, but they just don't achieve their goals--they only cause people to add a lot more code that, in the end, is no safer than what they started with.