在使用面对对象的编程语言是，程序员必须进行必要的异常处理，使得程序能够得以平稳运行。而异常处理的具体方式，则是根据程序员的喜好而有所不同。有的习惯于遇到异常就将其抛出，交给上层调用者去处理；有的而是自己处理；有的就干脆只是个摆设，即使出现异常也不进行任何处理。
从异常处理的几种方式我们可以发现，一个上层模块调用底层模块以获取必要的数据时，遇到底层模块采用自己处理异常或者发生异常不进行任何处理时，两者之间的通信就只是命令与结果，底层模块在获取命令后，是怎样处理出结果，上层模块也就无从知晓了，因为底层模块总是根据不同的命令，返回不同的结果，而且仅仅是结果。要是底层模块在执行命令的过程中遇到异常，要么自己正确的处理异常；要么未能正常处理，只能返回错误的结果；要么就发生错误，然后程序死掉……而对于上层模块来说，在调用下层模块之后，要么得到正确的结果，要么就是错误的，要么什么也得不到，程序出现未知错误而死掉。
如果说底层模块在遇到异常后，不进行处理，或者说只是进行简单而必要的处理，比如说进行抽象和概括，然后将异常信息抛出，交给上层调用者去处理。上层调用者在得到异常信息后再进行相应的操作，这样看起来是一个不错的选择，因为上层调用者很清楚自己需要什么，根据异常信息可以采取相应的正确操作。但是，要知道，对于上层模块所获得的异常信息是由底层模块抛出的，而且绝大多是还是进行过抽象和概括的，另外底层模块执行命令到什么地方后无法执行，而抛出异常，或者是怎么抛出的，上层模块并不知情，或者说没法理解底层模块所抛出的异常，这样一来即使知道异常信息，但也没法做出正确的处理。要是层级再多一点，每一层都将异常信息予以抽象和概括，最终，程序的最高层，也就完全不知道是怎么回事了，即便是知道异常信息，也知道该怎么处理，但却难以执行异常信息的具体来源，所以也就无从下手了。也许我们会想到，既然如此，那么底层在抛出异常时就不要进行抽象和概括，将异常信息原样抛出，但是要知道对于一个程序来说，上层模块也就那么几个，而旗下的底层模块则是多得数不清，每一个底层模块都将异常信息原样抛出，想想，会抛出多少异常，上层模块处理得过来吗？再者，还是同样的道理，虽然知道异常信息，但却不知道底层模块为什么会抛出异常，又是在哪里抛出的异常……
再高级的程序设计语言，也都是人造的，而前辈们在设计一门语言时，更是尽可能的参照现实世界中的语言，让程序语言更加接近于自然语言。所以每一种程序设计语言都会或多或少的折射出现实世界的某一个方面。让我们想想，要是某地发生的水灾，农户在往村里上报灾情时，是说张家死了一头牛，王家房屋被淹了，李家丢了3只羊…………而村里统计出灾情后加以必要的抽象和概括再往镇里报，也就成了：村，死了**头牛，丢了只羊，淹了房屋……镇上统计出灾情后再次进行必要抽象和概括，然后往县里上报，县上在往市里报，市里再往省上报，要是灾情很严重最后上报到了中央，中央得到的灾情也就是地方遭受严重水灾，受灾群众达万人次，受灾面积达公顷，直接经济损失达**万元……
既然发生了灾情，那么政府部门也就得进行救灾，上级部门根据下级部门上报的灾情进行相应的救灾处理。现在信息流倒过来了，而对于信息的处理方式也就反过来了，一层一层的细化，在中央，还是拨万救灾资金，物资……而到了具体受灾群众的手里，则是一床棉被，一瓶矿泉水（当然，救灾方式也不会这么苛刻）……从普通农户到最高层领导不能，期间要进过无数的政府部门，一层一层的往上报，这一过程中又都是人在操作，并且每一层都会对下级部门上报的结果进行抽象和概括，信息在上报的过程中具体发生了什么，谁也说不清楚了……
现在想想，终于明白领导们为什么天天开会了（越是大领导越是如此），因为对于一个社会群体，领导阶层毕竟是少数，要让这么一少部分人去了解整个社会群体的信息，要是让他么挨个去了解，那肯定会出人命。所以分成管理也就自然而然的出现了，每一个层级有着不同的工作，而上级部门要了解民情，也就只有依靠下级部门的汇报；要下拨命令或消息也只能一层一层的转达……而且这些都是关系到千千万万群众的事，所以必须集思广益，领导们坐在一起，不断讨论，最终得出大多数都同意的方案……所以，也就有了领导天天开会的结果……
由于上级部门的信息来源都是下级部门抽象概括后上报，所以也就加大了对信息的理解难度，也就难以作出正确的决策。而要是遇到下级部门隐瞒不报，那也就完全不知道该怎么办了……短期内还没什么，但是长此以往，必将发生不可调和得矛盾，所以也就出现了普查民意，大众调查，或者说“微服私访”的出现……
而这些现象的出现，归根结底还是因为信息的交流方式和信息的共享范围。信息的交流方式产生了分成管理，而信息的共享范围则导致了各种各样的社会矛盾。