Talk:Teleinterface
From APIDesign
(teleinterface for exceptions) |
|||
Line 11: | Line 11: | ||
Nicolas Dumoulin, Cemagref, France | Nicolas Dumoulin, Cemagref, France | ||
--[[Special:Contributions/195.221.117.88|195.221.117.88]] 08:54, 19 May 2010 (UTC) | --[[Special:Contributions/195.221.117.88|195.221.117.88]] 08:54, 19 May 2010 (UTC) | ||
+ | |||
+ | |||
+ | Hello Nicolas, you are right, this looks like a [[Teleinterface]]. We should extract your thoughts to [[Teleexception]] page. Few questions: | ||
+ | # ''process'' method throws various exceptions which of them is the [[teleport]] container? | ||
+ | # Maybe you could use <source lang="java"> to show the most important [[API]] signatures at this page | ||
+ | # ''wrapping an exception'' is basically using initCause(...) and getCause later, right? | ||
+ | # btw: another option that I use from time to time is to subclass exceptions (MyOwnIOException with big details extends IOException). This however requires some common exception subclass like IOException, or having method signature throw Exception (a bit ugly). | ||
+ | Feel free to answer my questions here or directly move your text to [[Teleexception]]. Thanks. | ||
+ | |||
+ | --[[User:JaroslavTulach|JaroslavTulach]] 06:38, 28 May 2010 (UTC) |
Current revision
I think that an other way to realize a Teleinterface is when you wrap a specific (business related) exception in a high level exception. We (me and my coworkers) usually use exception wrapping when we design our API.
For example, we have a class in a central module of our API that serves for abstract tasks execution (like the method process in this class).
Now, consider that we add a module that will implements this class and perform instructions in this method process. If a part of these instructions can throw an exception related to used libraries for example, we catch and wrap this exception in a high-level exception defined by our first module (used in the prototype of our abstract method process).
Then, in another class in this second module (or in a module that have dependencies on this second module or its dependencies defining the catched exception), if we make a call to the high-level process we can catch exception, and we have an additionial knowledge in possible wrapped exception, so we can make specific processing if the wrapped exception is of a type that was catched in the second module.
I don't know if my explanation are enough clear, but I think that in this case, we can say that the business related exception, wrapped in a high-level exception, can be fetched by a consumer class without any consciousness in the API, and is de facto teleported.
Nicolas Dumoulin, Cemagref, France --195.221.117.88 08:54, 19 May 2010 (UTC)
Hello Nicolas, you are right, this looks like a Teleinterface. We should extract your thoughts to Teleexception page. Few questions:
- process method throws various exceptions which of them is the teleport container?
- Maybe you could use <source lang="java"> to show the most important API signatures at this page
- wrapping an exception is basically using initCause(...) and getCause later, right?
- btw: another option that I use from time to time is to subclass exceptions (MyOwnIOException with big details extends IOException). This however requires some common exception subclass like IOException, or having method signature throw Exception (a bit ugly).
Feel free to answer my questions here or directly move your text to Teleexception. Thanks.
--JaroslavTulach 06:38, 28 May 2010 (UTC)