JaroslavTulach at 06:38, 28 May 2010 - 2010-05-28 06:38:11

←Older revision Revision as of 06:38, 28 May 2010
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)

195.221.117.88: teleinterface for exceptions - 2010-05-19 08:54:26

teleinterface for exceptions

New page

I think that an other way to realize a [[Teleinterface]] is when you wrap a specific (business related) [[APIDesignPatterns:Exceptions|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 [http://hudson.simexplorer.org/job/openmole-javadoc/javadoc/org/openmole/core/workflow/implementation/task/GenericTask.html 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
--[[Special:Contributions/195.221.117.88|195.221.117.88]] 08:54, 19 May 2010 (UTC)