BuilderWithConditionalException - Revision history

JaroslavTulach: /* Summary */

2016-06-13T07:55:54Z

Summary

←Older revision		Revision as of 07:55, 13 June 2016
Line 82:		Line 82:
	== Summary ==		== Summary ==

-	By giving the [[builder]] a generic error type we allow fine grain control over possible errors states that may accumulate when calling various [[builder]] configuration methods. The whole solution keeps the runtime behavior of the [[builder]] pattern - after applying [[erasure]] of generic types, the whole type information (visible to compiler and [[API] user) disappears.	+	By giving the [[builder]] a generic error type we allow fine grain control over possible errors states that may accumulate when calling various [[builder]] configuration methods. The whole solution keeps the runtime behavior of the [[builder]] pattern - after applying [[erasure]] of generic types, the whole type information (visible to compiler and [[API]] user) disappears.

2016-06-13T07:55:44Z

Summary

←Older revision		Revision as of 07:55, 13 June 2016
Line 82:		Line 82:
	== Summary ==		== Summary ==

-	By giving the [[builder]] a generic error type we allow fine grain control over possible errors states that may accumulate when calling various [[builder]] configuration methods. The whole solution keeps the runtime behavior of the [[builder]] pattern - after applying [[erasure]] of generic types, the whole type information (visible to compiler) disappears.	+	By giving the [[builder]] a generic error type we allow fine grain control over possible errors states that may accumulate when calling various [[builder]] configuration methods. The whole solution keeps the runtime behavior of the [[builder]] pattern - after applying [[erasure]] of generic types, the whole type information (visible to compiler and [[API] user) disappears.

2016-06-13T07:54:34Z

Changing the State

←Older revision		Revision as of 07:54, 13 June 2016
Line 72:		Line 72:
	</source>		</source>

-	Obviously, when one specifies the content directly, there is no I/O when the ''build()'' method is called and there should be no need to require catching an {{JDK\|java/io\|IOException}}. With the above change one can start with a builder based on ''newFromFile'', and still switch to mode that doesn't throw an {{JDK\|java/io\|IOException}} at all:	+	Obviously, when one specifies the content directly, there is no I/O when the ''build()'' method is called and there should be no need to require catching of an {{JDK\|java/io\|IOException}}. With the above change one can start with a builder based on ''newFromFile'', and still switch to mode that doesn't throw an {{JDK\|java/io\|IOException}} at all:

	<source lang="java">		<source lang="java">

2016-06-13T07:51:54Z

Builder for Source

←Older revision		Revision as of 07:51, 13 June 2016
Line 3:		Line 3:
	== Builder for Source ==		== Builder for Source ==

-	These days [[I]] am trying to use the [[builder]] pattern also for construction of {{truffle\|com/oracle/truffle/api/source\|Source}}. Rather than having various (and overloaded) methods ~~name~~ '''fromFileName''' with various number and order of parameters, etc. we'd like to have:	+	These days [[I]] am trying to use the [[builder]] pattern also for construction of {{truffle\|com/oracle/truffle/api/source\|Source}}. Rather than having various (and overloaded) methods named '''fromFileName''' with various number and order of parameters, etc. we'd like to have:

	<source lang="java">		<source lang="java">

2016-06-10T14:16:12Z

Changing the State

←Older revision		Revision as of 14:16, 10 June 2016
Line 72:		Line 72:
	</source>		</source>

-	~~Now~~ one can start with a builder based on ''newFromFile'', and still switch to mode that doesn't throw an {{JDK\|java/io\|IOException}} at all:	+	Obviously, when one specifies the content directly, there is no I/O when the ''build()'' method is called and there should be no need to require catching an {{JDK\|java/io\|IOException}}. With the above change one can start with a builder based on ''newFromFile'', and still switch to mode that doesn't throw an {{JDK\|java/io\|IOException}} at all:

	<source lang="java">		<source lang="java">
	Source source = Source.newFromFile(file).		Source source = Source.newFromFile(file).
-	~~mimetype("text/javascript").~~
-	~~name("FancyName.js").~~
	content("var x = 42\n").		content("var x = 42\n").
	build(); // no IOException at all		build(); // no IOException at all

2016-06-10T14:13:42Z

Throw only for I/O

←Older revision		Revision as of 14:13, 10 June 2016
Line 38:		Line 38:
	=== Throw only for I/O ===		=== Throw only for I/O ===

-	The option that [[I]] came up with is to parametrize the builder with the exception the ''build()'' method is going to throw:	+	The option that [[I]] came up with is to parametrize the [[builder]] with the exception the ''build()'' method is going to throw:

	<source lang="java">		<source lang="java">

2016-06-10T14:13:28Z

Throw only for I/O

←Older revision		Revision as of 14:13, 10 June 2016
Line 38:		Line 38:
	=== Throw only for I/O ===		=== Throw only for I/O ===

-	The option that [[I]] ~~come~~ up with is to parametrize the builder with the exception the ''build()'' method is going to throw:	+	The option that [[I]] came up with is to parametrize the builder with the exception the ''build()'' method is going to throw:

	<source lang="java">		<source lang="java">

2016-06-10T14:12:35Z

Throw on I/O Error

←Older revision		Revision as of 14:12, 10 June 2016
Line 25:		Line 25:
	</source>		</source>

-	However there is more. The [[builder]] may also construct a {{truffle\|com/oracle/truffle/api/source\|Source} object from already provided text. The usage looks like:	+	However there is more. The [[builder]] may also construct a {{truffle\|com/oracle/truffle/api/source\|Source}} object from already provided text. The usage looks like:

	<source lang="java">		<source lang="java">

2016-06-10T14:11:40Z

Builder for Source

←Older revision		Revision as of 14:11, 10 June 2016
Line 3:		Line 3:
	== Builder for Source ==		== Builder for Source ==

-	These days [[I]] am trying to use the [[builder]] pattern also for construction of {{truffle\|com/oracle/truffle/api/source\|Source}}. Rather than having various (and overloaded) methods ~~with~~ '''fromFileName''', etc. we'd like to have:	+	These days [[I]] am trying to use the [[builder]] pattern also for construction of {{truffle\|com/oracle/truffle/api/source\|Source}}. Rather than having various (and overloaded) methods name '''fromFileName''' with various number and order of parameters, etc. we'd like to have:

	<source lang="java">		<source lang="java">

2016-06-10T14:09:12Z

Changing the State

←Older revision		Revision as of 14:09, 10 June 2016
Line 72:		Line 72:
	</source>		</source>

-	Now one can start with a builder based on ''newFromFile'', and still switch to mode that doesn't throw an ~~exception~~ at all.	+	Now one can start with a builder based on ''newFromFile'', and still switch to mode that doesn't throw an {{JDK\|java/io\|IOException}} at all:
		+
		+	<source lang="java">
		+	Source source = Source.newFromFile(file).
		+	mimetype("text/javascript").
		+	name("FancyName.js").
		+	content("var x = 42\n").
		+	build(); // no IOException at all
		+	</source>
		+
		+	== Summary ==
		+
		+	By giving the [[builder]] a generic error type we allow fine grain control over possible errors states that may accumulate when calling various [[builder]] configuration methods. The whole solution keeps the runtime behavior of the [[builder]] pattern - after applying [[erasure]] of generic types, the whole type information (visible to compiler) disappears.
		+
		+
		+	[[Category:APIDesignPatterns]]
		+	[[Category:APIDesignPatterns:Creational]]
		+	[[Category:APIDesignPatterns:Exceptions]]