日期:2011-03-22 16:17:00 来源:本站整理
java违例的限制[Java编程]
本文“java违例的限制[Java编程]”是由七道奇为您精心收集,来源于网络转载,文章版权归文章作者所有,本站不对其观点以及内容做任何评价,请读者自行判断,以下是其具体内容:
覆盖一个办法时,只能产生已在办法的底子类版本中定义的违例.这是一个重要的限制,因为它意味着与底子类协同工作的代码也会自动利用于从底子类衍生的任何对象(当然,这属于基本的OOP概念),此中包含违例.
下面这个例子演示了强加在违例身上的限制范例(在编译期):
//: StormyInning.java // Overridden methods may throw only the // exceptions specified in their base-class // versions, or exceptions derived from the // base-class exceptions. class BaseballException extends Exception {} class Foul extends BaseballException {} class Strike extends BaseballException {} abstract class Inning { Inning() throws BaseballException {} void event () throws BaseballException { // Doesn't actually have to throw anything } abstract void atBat() throws Strike, Foul; void walk() {} // Throws nothing } class StormException extends Exception {} class RainedOut extends StormException {} class PopFoul extends Foul {} interface Storm { void event() throws RainedOut; void rainHard() throws RainedOut; } public class StormyInning extends Inning implements Storm { // OK to add new exceptions for constructors, // but you must deal with the base constructor // exceptions: StormyInning() throws RainedOut, BaseballException {} StormyInning(String s) throws Foul, BaseballException {} // Regular methods must conform to base class: //! void walk() throws PopFoul {} //Compile error // Interface CANNOT add exceptions to existing // methods from the base class: //! public void event() throws RainedOut {} // If the method doesn't already exist in the // base class, the exception is OK: public void rainHard() throws RainedOut {} // You can choose to not throw any exceptions, // even if base version does: public void event() {} // Overridden methods can throw // inherited exceptions: void atBat() throws PopFoul {} public static void main(String[] args) { try { StormyInning si = new StormyInning(); si.atBat(); } catch(PopFoul e) { } catch(RainedOut e) { } catch(BaseballException e) {} // Strike not thrown in derived version. try { // What happens if you upcast? Inning i = new StormyInning(); i.atBat(); // You must catch the exceptions from the // base-class version of the method: } catch(Strike e) { } catch(Foul e) { } catch(RainedOut e) { } catch(BaseballException e) {} } } ///:~
在Inning中,可以看到无论构建器还是event()办法都指出自己会“掷”出一个违例,但它们实际上没有那样做.这是合理的,因为它答应我们逼迫用户捕捉大概在覆盖过的event()版本里增添的任何违例.一样的原理也实用于abstract办法,就象在atBat()里展示的那样.
“interface Storm”非常风趣,因为它包含了在Incoming中定义的一个办法——event(),以及不是在此中定义的一个办法.这两个办法城市“掷”出一个新的违例范例:RainedOut.当履行到“StormyInning extends”和“implements Storm”的时刻,可以看到Storm中的event()办法不能改变Inning中的event()的违例接口.一样地,这种计划是非常公道的;不然的话,当我们操作底子类时,便根本无法知道自己捕捉的能否精确的东西.当然,假定interface中定义的一个办法不在底子类里,比方rainHard(),它产生违例时就没什么问题.
对违例的限制并不实用于构建器.在StormyInning中,我们可看到一个构建器可以“掷”出它但愿的任何东西,无论底子类构建器“掷”出什么.但是,由于必须保持按某种方法调用底子类构建器(在这里,会自动调用默许构建器),所以衍生类构建器必须在自己的违例标准中声明全部底子类构建器违例.
StormyInning.walk()不会编译的缘由是它“掷”出了一个违例,而Inning.walk()却不会“掷”出.若答应这种情形发生,便可以让自己的代码调用Inning.walk(),并且它没必要掌握任何违例.但在今后替换从Inning衍生的一个类的对象时,违例就会“掷”出,造成代码履行的中止.通过逼迫衍生类办法服从底子类办法的违例标准,对象的替换可保持联贯性.
覆盖过的event()办法向我们显示出一个办法的衍生类版本可以不产生任何违例——即便底子类版本要产生违例.一样地,这样做是必要的,因为它不会中止那些已假定底子类版本会产生违例的代码.差不多的原理亦实用于atBat(),它会“掷”出PopFoul——从Foul衍生出来的一个违例,而Foul违例是由atBat()的底子类版本产生的.这样一来,假定有人在自己的代码里操作Inning,同时调用了atBat(),就必须捕捉Foul违例.由于PopFoul是从Foul衍生的,所以违例掌握器(模块)也会捕捉PopFoul.
最后一个风趣的地方在main()内部.在这个地方,假定我们明确操作一个StormyInning对象,编译器就会逼迫我们只捕捉特定于那个类的违例.但假定我们上溯造型到底子范例,编译器就会逼迫我们捕捉针对底子类的违例.通过全部这些限制,违例掌握代码的“结实”程度得到了大幅度改进(注释③).
③:ANSI/ISO C++施加了近似的限制,要求衍生办法违例与底子类办法掷出的违例相同,大概从后者衍生.在这种情形下,C++实际上可以在编译期间查抄违例标准.
我们必须熟习到这一点:固然违例标准是由编译器在担当期间强行服从的,但违例标准并不属于办法范例的一部份,后者仅包含了办法名以及自变量范例.因此,我们不可在违例标准的底子上覆盖办法.除此以外,固然违例标准存在于一个办法的底子类版本中,但并不表示它必须在办法的衍生类版本中存在.这与办法的“担当”颇有差别(举行担当时,底子类中的办法也必须在衍生类中存在).换言之,用于一个特定办法的“违例标准接口”大概在担当和覆盖时变得更“窄”,但它不会变得更“宽”——这与担当时的类接口法则是恰好相反的.
以上是“java违例的限制[Java编程]”的内容,如果你对以上该文章内容感兴趣,你可以看看七道奇为您推荐以下文章:
本文地址: | 与您的QQ/BBS好友分享! |
- ·上一篇文章:用finally解除违例
- ·下一篇文章:成立自己的违例
- ·中查找“java违例的限制”更多相关内容
- ·中查找“java违例的限制”更多相关内容
评论内容只代表网友观点,与本站立场无关!
评论摘要(共 0 条,得分 0 分,平均 0 分)
查看完整评论