View source

From APIDesign

You do not have permission to do that, for the following reason:

The action you have requested is limited to users in the group Bureaucrats.

You can view and copy the source of this page:

Often when reasoning about [[APIDesignPatterns:Exceptions|exceptions]], they are thought to be somewhat special, not really full featured classes. At least many coding practices advice to not use them in such and such situations. As a result developers often do not think about using [[ExceptionExtensibility|inheritance]] or other object oriented aspects when dealing with [[APIDesignPatterns:Exceptions|exceptions]]. Sometimes this is justified, sometimes it can be too restricting. In [[Java]] [[APIDesignPatterns:Exceptions|exceptions]] are just like any regular classes and this can be sometimes used to achieve surprising results.

All developers think about exceptions as something that can be thrown and caught. Some know that it is useful to call exceptions' [[GettersAndSetters|getters]] to get more info about the failure represented by the exception. However only few explore design style where exceptions also contain [[GettersAndSetters|setters]] or other mutable methods. Not that it would make sense to modify state of the exception itself, as that is short living object, however the exception can serve as a bridge to some internal longer living object and can be its interface allowing changes to its state.

This imperative can be used to implement '''Try/Catch/Redo''' [[APIDesignPatterns|pattern]]. Imagine that some code deep inside of a set of I/O operations cannot proceed without asking a question. For example the [[NetBeans]] version control modules may need to ask the user whether file shall be ''locked'' before allowing its content to be changed. For that purpose they may implement a special [[ExceptionExtensibility|extended]] '''IOException''':

<source lang="java" snippet="trycatchredo.UserQuestionException"/>

This is just another '''IOException''', so for [[Cluelessness|clueless]] [[API]] users nothing changes. One can continue to write classical saving code:

<source lang="java" snippet="trycatchredo.SaveAction"/>

However in case one needs to provide support for safe ''queries'', one can extend the code to recognize the special exception and communicate with it:

<source lang="java" snippet="trycatchredo.SaveActionWithQuery"/>

The '''confirm''' method is the callback to the internals of the '''URLConnection''' provider, like the [[NetBeans]] version control modules. The '''confirm''' method can change the internal state, just like in simple ''stream'' example:

<source lang="java" snippet="trycatchredo.stream"/>

After ''confirming'' the desire to really ''lock'' the file, one can '''redo''' the whole operation. The stream's internal state is now changed and the whole operation successfully proceeds. 

==== Balance Simplicity and Flexibility ====

Some may say that exceptions are not suitable for regular code flow control and as such using the [[TryCatchRedo]] is more a misuse than a regular [[APIDesignPatterns|design pattern]], however this all depends on the frequency. 

If the '''UserQuestionException''' is used in 99% of cases, by such majority of users then this pattern is definitely not suitable. Calling once, at the ''try'' round, catching the exception and calling again is ridiculously complex. On the other hand if 99% of usages are OK with catching plain '''IOException''' then this pattern is a nice example of making simple things easy and complex possible.



[[Category:APIDesignPatterns]]
[[Category:APIDesignPatterns:Exceptions]]

Return to TryCatchRedo.

Retrieved from "http://wiki.apidesign.org/wiki/TryCatchRedo"

View source

From APIDesign

Views

Personal tools

blogs & look

Navigation

Search

Toolbox

View source

From APIDesign

Views

Personal tools

blogs & look

Navigation

Search

Toolbox

buy