JaroslavTulach at 15:27, 2 February 2009 - 2009-02-02 15:27:14

←Older revision Revision as of 15:27, 2 February 2009
Line 1: Line 1:
-
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.
+
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 situations where regular objects would be more than appropriate. 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 class 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.
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''':
+
This imperative style 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. Showing dialog by itself is big ''no-no'' for low level I/O libraries as it often leads to [[deadlock]]s when fighting for the shared screen. Instead imagine that there is a special [[ExceptionExtensibility|extended]] '''IOException''':
<source lang="java" snippet="trycatchredo.UserQuestionException"/>
<source lang="java" snippet="trycatchredo.UserQuestionException"/>
Line 15: Line 15:
<source lang="java" snippet="trycatchredo.SaveActionWithQuery"/>
<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:
+
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 this simple ''stream'' example:
<source lang="java" snippet="trycatchredo.stream"/>
<source lang="java" snippet="trycatchredo.stream"/>
Line 25: Line 25:
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.
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. To implement this kind of communication without use of exception would create quite rich [[API]] - overly complex for those 99% of its users.
+
If the '''UserQuestionException''' is used in 99% of cases, by 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. To implement this kind of communication without use of exception would create quite rich [[API]] - overly complex for those 99% of its users.
-
Actually this is nice example of a [[Teleinterface]], a ''bottleneck'' [[API]], based on simplistic assumptions, which allows rich communication between the [[API]] user and provider that both decide to understand the enhanced '''UserQuestionException'''. While communication for 99% of users stays the same and simplified.
+
Actually this is nice example of a [[Teleinterface]], a ''bottleneck'' [[API]], based on simplistic assumptions, which allows rich communication between the [[API]] user and provider that both decide to understand the enhanced '''UserQuestionException'''. The basic ''URL'' [[API]] does not even know that the enhanced communication is going on. Neither 99% of its users. Still, such exception can be teleported from the [[API]] provider to the [[API]] client if necessary.
 +
<comments/>
[[Category:APIDesignPatterns]]
[[Category:APIDesignPatterns]]
[[Category:APIDesignPatterns:Exceptions]]
[[Category:APIDesignPatterns:Exceptions]]

JaroslavTulach: /* Balance Simplicity and Flexibility */ - 2009-02-01 20:17:17

Balance Simplicity and Flexibility

←Older revision Revision as of 20:17, 1 February 2009
Line 25: Line 25:
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.
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.
+
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. To implement this kind of communication without use of exception would create quite rich [[API]] - overly complex for those 99% of its users.
 +
Actually this is nice example of a [[Teleinterface]], a ''bottleneck'' [[API]], based on simplistic assumptions, which allows rich communication between the [[API]] user and provider that both decide to understand the enhanced '''UserQuestionException'''. While communication for 99% of users stays the same and simplified.
[[Category:APIDesignPatterns]]
[[Category:APIDesignPatterns]]
[[Category:APIDesignPatterns:Exceptions]]
[[Category:APIDesignPatterns:Exceptions]]

JaroslavTulach at 19:59, 1 February 2009 - 2009-02-01 19:59:11

←Older revision Revision as of 19:59, 1 February 2009
Line 20: Line 20:
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.
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]]
[[Category:APIDesignPatterns:Exceptions]]
[[Category:APIDesignPatterns:Exceptions]]

JaroslavTulach at 17:42, 1 February 2009 - 2009-02-01 17:42:15

←Older revision Revision as of 17:42, 1 February 2009
Line 1: Line 1:
-
Often when thinking 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 techniques when dealing with [[APIDesignPatterns:Exceptions|exceptions]]. Sometimes this is justified, sometimes it is too restricting approach. In [[Java]] [[APIDesignPatterns:Exceptions|exceptions]] are just like any regular classes and this can sometimes be used to achieve surprising results.
+
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 where exceptions also contain [[GettersAndSetters|setters]] or other mutable methods. Not that it would make sense to modify state of exception, as that is short living object, however the exception can serve as bridge to some internal longer living object and can server as an interface that changes its state.
+
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 use to implement '''Try/Catch/Redo''' [[APIDesignPatterns|pattern]]. Imagine that some code deep inside of 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''':
+
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"/>
<source lang="java" snippet="trycatchredo.UserQuestionException"/>
Line 15: Line 15:
<source lang="java" snippet="trycatchredo.SaveActionWithQuery"/>
<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 or this simple ''stream'' that can ask questions:
+
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"/>
<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.
[[Category:APIDesignPatterns]]
[[Category:APIDesignPatterns]]
[[Category:APIDesignPatterns:Exceptions]]
[[Category:APIDesignPatterns:Exceptions]]

JaroslavTulach: New page: Often when thinking about exceptions, they are thought to be somewhat special, not really full featured classes. At least many coding practices advice to n... - 2009-02-01 16:49:35

New page: Often when thinking about exceptions, they are thought to be somewhat special, not really full featured classes. At least many coding practices advice to n...

New page

Often when thinking 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 techniques when dealing with [[APIDesignPatterns:Exceptions|exceptions]]. Sometimes this is justified, sometimes it is too restricting approach. In [[Java]] [[APIDesignPatterns:Exceptions|exceptions]] are just like any regular classes and this can sometimes be 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 where exceptions also contain [[GettersAndSetters|setters]] or other mutable methods. Not that it would make sense to modify state of exception, as that is short living object, however the exception can serve as bridge to some internal longer living object and can server as an interface that changes its state.

This imperative can be use to implement '''Try/Catch/Redo''' [[APIDesignPatterns|pattern]]. Imagine that some code deep inside of 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 or this simple ''stream'' that can ask questions:

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



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