You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tinkerpop.apache.org by David Robinson <dr...@gmail.com> on 2015/09/01 20:00:26 UTC
Vertex.value throws (unchecked) RunTimeException
In Element.java (org.apache.tinkerpop.gremlin.structure.Element.java)
the value(...) method throws NoSuchElementException:
* @throws NoSuchElementException if the property does not exist on the
{@code Element}.
*/
public default <V> V value(final String key) throws
NoSuchElementException {
NoSuchElementException extends RunTimeException which is a unchecked
exception.
Since this is an unchecked exception, the compiler does not force code
doing a v.value() to catch an exception, which can lead to nasty results.
In some Java circles, it is considered bad practice to catch
RunTimeExceptions anyway.
Should the exception thrown be changed to a checked exception - something
like "ValueDoesNotExist" that extends Exception ? This would become a
checked exception and will lead to better code based on TP 3.1.0
Another alternative is for the value() method to simply return null (it
might have done this in TP 2.x ?) or change the signature of the value()
method so that a default value is supplied: value('key",
"default-if-not-set").
Sounds like JIRA to me, but I wanted to see other's thoughts first.
Thanks,
Re: Vertex.value throws (unchecked) RunTimeException
Posted by David Robinson <dr...@gmail.com>.
I appreciate this exchange. Quite useful from my perspective.
This was not started as a hypothetical discussion but is based in actual
experience trying to use TinkerPop 3 and Titan 0.9.x.
The impression from that experience is that TP3 imposes too much complexity
on the application programmer. A bad user enablement story.
One use case involves an application that interacts with a Titan graph, but
the precise schema of the
graph is not know until run time. Further, the exact graph schema can
differ from environment
to environment.
Autoschema in Titan is turned off - mgmt commands are used to define a
schema.
But the schema definition is dynamic as properties “arise”. Think IoT to
get a ballpark
idea of the specific app.
Titan mgmt calls are made at appropriate times to define properties. But
the overall application doesn’t know ahead of time precisely the defintions
- and even
if it does, because this is on a cluster, there are timing windows when a
new definition
is made and not yet propagated.
As far as we can tell, the following chunk of code is required to read a
node property if
a developer wants to avoid generating unchecked exceptions, which make
program logic
difficult to handle neatly. As a general rule, we do not catch unchecked
exceptions as bad
practice.
Not only is this a lot of code, but it is slow - requiring several API
calls.
public final Object getProperty(Element e, String propertyName) throw
NotDefinedException {
com.thinkaurelius.titan.core.PropertyKey key =
mgmt.getPropertyKey(propertyName);
if (null == key){
throw new NotDefinedException("Cannot locate property key
definition: "+propertyName);
}
if (key.cardinality().equals(Cardinality.SINGLE)){
if (! e.property(propertyName).isPresent()){
return null;
}
return e.value(propertyName);
}
Iterator<? extends Property<Object>> ret = e.properties(propertyName);
if (! ret.hasNext()){
return null;
}
LinkedList<Object> props = new LinkedList<>();
while (ret.hasNext()){
props.add(ret.next().value());
}
return props;
}
If I am not mistaken with behavior, Titan 0.5.4 “had it right” - unset
properties returned null,
multiproperties returned an Iterable on getProperty...and all of this was
accomplished efficiently
in a few lines of code and ran faster.
On Fri, Sep 4, 2015 at 1:30 PM, pieter-gmail <pi...@gmail.com>
wrote:
> Yeah, maybe a vertex.isMultiProperty(key) will be good to avoid people
> from having to use exception handling as logic flow.
>
> Cheers
> Pieter
>
> On 03/09/2015 18:28, Stephen Mallette wrote:
> > Element.property(k) is meant to return a single property so if you call
> it
> > on something that is a multi-property then you are calling it at an
> illegal
> > or inappropriate time given your schema. I think that was the reason for
> > our usage of that exception - might be taking some liberties there, but I
> > think it's reasonable.
> >
> >
> > On Wed, Sep 2, 2015 at 1:50 AM, pieter-gmail <pi...@gmail.com>
> > wrote:
> >
> >> Hi,
> >>
> >> I checked, neither Neo4jProperty nor TinkerProperty throws an exception
> >> on isPresent()
> >>
> >> @Override
> >> public boolean isPresent() {
> >> return null != this.value;
> >> }
> >>
> >> Your exception is coming from the Vertex, which means the isPresent()
> >> check is useless to you.
> >> I never use multi/meta properties but I do now get your point.
> >>
> >> Probably in your case it should return a VertexProperty for which
> >> isPresent will be false.
> >>
> >> Cheers
> >> Pieter
> >>
> >> On 01/09/2015 21:55, David Robinson wrote:
> >>> Hi Pieter,
> >>>
> >>> Thank you for the response.
> >>>
> >>> Checked and unchecked exceptions in Java certainly have created
> >> interesting
> >>> discussions, but unchecked exceptions are intended for unexpected
> >>> conditions.
> >>>
> >>> Maybe the TP code should not throw an exception, but since it does, it
> >>> should
> >>> be a checked exception.
> >>>
> >>> isPresent() is a nice suggestion, however, it also throws a
> >>> RunTimeException.
> >>> So I hope if you are using isPresent() you are at least catching
> >>> RunTimeExceptions
> >>> as a guard.
> >>>
> >>> Consider the following Java code:
> >>>
> >>> try {
> >>> Graph graph = TinkerGraph.open();
> >>>
> >>> Vertex v1 = graph.addVertex("name", "value1", "name", "value2");
> >>>
> >>> v1.property("name").isPresent();
> >>> }
> >>> catch (Exception e) {
> >>> e.printStackTrace();
> >>> }
> >>>
> >>> This code will throw this exception:
> >>>
> >>> java.lang.IllegalStateException: Multiple properties exist for the
> >> provided
> >>> key, use Vertex.properties(name)
> >>> ..........
> >>>
> >>> which is also a RunTimeException:
> >>>
> >>
> https://docs.oracle.com/javase/8/docs/api/java/lang/IllegalStateException.html
> >>> If you read the text for IllegalStateException, this does not appear to
> >> be
> >>> an appropriate use of this exception:
> >>>>> Signals that a method has been invoked at an illegal or inappropriate
> >>> time. In other words, the Java environment or Java >> application is
> not
> >> in
> >>> an appropriate state for the requested operation.
> >>>
> >>> The example raises another point around the difficulty of retrieving
> >>> multi-properties right now -but that
> >>> is for a different thread.
> >>>
> >>>
> >>> On Tue, Sep 1, 2015 at 2:16 PM, pieter-gmail <pi...@gmail.com>
> >>> wrote:
> >>>
> >>>> That exception has kinda gotten me to always first get the property
> then
> >>>> check isPresent()
> >>>>
> >>>> But no, I would not want any checked exceptions. In some circles that
> is
> >>>> also considered bad practice.
> >>>>
> >>>> Cheers
> >>>> Pieter
> >>>>
> >>>>
> >>>>
> >>>> On 01/09/2015 20:00, David Robinson wrote:
> >>>>> In Element.java (org.apache.tinkerpop.gremlin.structure.Element.java)
> >>>>> the value(...) method throws NoSuchElementException:
> >>>>>
> >>>>>
> >>>>> * @throws NoSuchElementException if the property does not exist
> on
> >>>> the
> >>>>> {@code Element}.
> >>>>> */
> >>>>> public default <V> V value(final String key) throws
> >>>>> NoSuchElementException {
> >>>>>
> >>>>>
> >>>>>
> >>>>> NoSuchElementException extends RunTimeException which is a unchecked
> >>>>> exception.
> >>>>>
> >>>>> Since this is an unchecked exception, the compiler does not force
> code
> >>>>> doing a v.value() to catch an exception, which can lead to nasty
> >> results.
> >>>>> In some Java circles, it is considered bad practice to catch
> >>>>> RunTimeExceptions anyway.
> >>>>>
> >>>>> Should the exception thrown be changed to a checked exception -
> >> something
> >>>>> like "ValueDoesNotExist" that extends Exception ? This would
> become a
> >>>>> checked exception and will lead to better code based on TP 3.1.0
> >>>>>
> >>>>> Another alternative is for the value() method to simply return null
> (it
> >>>>> might have done this in TP 2.x ?) or change the signature of the
> >> value()
> >>>>> method so that a default value is supplied: value('key",
> >>>>> "default-if-not-set").
> >>>>>
> >>>>> Sounds like JIRA to me, but I wanted to see other's thoughts first.
> >>>>>
> >>>>> Thanks,
> >>>>>
> >>
>
>
Re: Vertex.value throws (unchecked) RunTimeException
Posted by pieter-gmail <pi...@gmail.com>.
Yeah, maybe a vertex.isMultiProperty(key) will be good to avoid people
from having to use exception handling as logic flow.
Cheers
Pieter
On 03/09/2015 18:28, Stephen Mallette wrote:
> Element.property(k) is meant to return a single property so if you call it
> on something that is a multi-property then you are calling it at an illegal
> or inappropriate time given your schema. I think that was the reason for
> our usage of that exception - might be taking some liberties there, but I
> think it's reasonable.
>
>
> On Wed, Sep 2, 2015 at 1:50 AM, pieter-gmail <pi...@gmail.com>
> wrote:
>
>> Hi,
>>
>> I checked, neither Neo4jProperty nor TinkerProperty throws an exception
>> on isPresent()
>>
>> @Override
>> public boolean isPresent() {
>> return null != this.value;
>> }
>>
>> Your exception is coming from the Vertex, which means the isPresent()
>> check is useless to you.
>> I never use multi/meta properties but I do now get your point.
>>
>> Probably in your case it should return a VertexProperty for which
>> isPresent will be false.
>>
>> Cheers
>> Pieter
>>
>> On 01/09/2015 21:55, David Robinson wrote:
>>> Hi Pieter,
>>>
>>> Thank you for the response.
>>>
>>> Checked and unchecked exceptions in Java certainly have created
>> interesting
>>> discussions, but unchecked exceptions are intended for unexpected
>>> conditions.
>>>
>>> Maybe the TP code should not throw an exception, but since it does, it
>>> should
>>> be a checked exception.
>>>
>>> isPresent() is a nice suggestion, however, it also throws a
>>> RunTimeException.
>>> So I hope if you are using isPresent() you are at least catching
>>> RunTimeExceptions
>>> as a guard.
>>>
>>> Consider the following Java code:
>>>
>>> try {
>>> Graph graph = TinkerGraph.open();
>>>
>>> Vertex v1 = graph.addVertex("name", "value1", "name", "value2");
>>>
>>> v1.property("name").isPresent();
>>> }
>>> catch (Exception e) {
>>> e.printStackTrace();
>>> }
>>>
>>> This code will throw this exception:
>>>
>>> java.lang.IllegalStateException: Multiple properties exist for the
>> provided
>>> key, use Vertex.properties(name)
>>> ..........
>>>
>>> which is also a RunTimeException:
>>>
>> https://docs.oracle.com/javase/8/docs/api/java/lang/IllegalStateException.html
>>> If you read the text for IllegalStateException, this does not appear to
>> be
>>> an appropriate use of this exception:
>>>>> Signals that a method has been invoked at an illegal or inappropriate
>>> time. In other words, the Java environment or Java >> application is not
>> in
>>> an appropriate state for the requested operation.
>>>
>>> The example raises another point around the difficulty of retrieving
>>> multi-properties right now -but that
>>> is for a different thread.
>>>
>>>
>>> On Tue, Sep 1, 2015 at 2:16 PM, pieter-gmail <pi...@gmail.com>
>>> wrote:
>>>
>>>> That exception has kinda gotten me to always first get the property then
>>>> check isPresent()
>>>>
>>>> But no, I would not want any checked exceptions. In some circles that is
>>>> also considered bad practice.
>>>>
>>>> Cheers
>>>> Pieter
>>>>
>>>>
>>>>
>>>> On 01/09/2015 20:00, David Robinson wrote:
>>>>> In Element.java (org.apache.tinkerpop.gremlin.structure.Element.java)
>>>>> the value(...) method throws NoSuchElementException:
>>>>>
>>>>>
>>>>> * @throws NoSuchElementException if the property does not exist on
>>>> the
>>>>> {@code Element}.
>>>>> */
>>>>> public default <V> V value(final String key) throws
>>>>> NoSuchElementException {
>>>>>
>>>>>
>>>>>
>>>>> NoSuchElementException extends RunTimeException which is a unchecked
>>>>> exception.
>>>>>
>>>>> Since this is an unchecked exception, the compiler does not force code
>>>>> doing a v.value() to catch an exception, which can lead to nasty
>> results.
>>>>> In some Java circles, it is considered bad practice to catch
>>>>> RunTimeExceptions anyway.
>>>>>
>>>>> Should the exception thrown be changed to a checked exception -
>> something
>>>>> like "ValueDoesNotExist" that extends Exception ? This would become a
>>>>> checked exception and will lead to better code based on TP 3.1.0
>>>>>
>>>>> Another alternative is for the value() method to simply return null (it
>>>>> might have done this in TP 2.x ?) or change the signature of the
>> value()
>>>>> method so that a default value is supplied: value('key",
>>>>> "default-if-not-set").
>>>>>
>>>>> Sounds like JIRA to me, but I wanted to see other's thoughts first.
>>>>>
>>>>> Thanks,
>>>>>
>>
Re: Vertex.value throws (unchecked) RunTimeException
Posted by Stephen Mallette <sp...@gmail.com>.
Element.property(k) is meant to return a single property so if you call it
on something that is a multi-property then you are calling it at an illegal
or inappropriate time given your schema. I think that was the reason for
our usage of that exception - might be taking some liberties there, but I
think it's reasonable.
On Wed, Sep 2, 2015 at 1:50 AM, pieter-gmail <pi...@gmail.com>
wrote:
> Hi,
>
> I checked, neither Neo4jProperty nor TinkerProperty throws an exception
> on isPresent()
>
> @Override
> public boolean isPresent() {
> return null != this.value;
> }
>
> Your exception is coming from the Vertex, which means the isPresent()
> check is useless to you.
> I never use multi/meta properties but I do now get your point.
>
> Probably in your case it should return a VertexProperty for which
> isPresent will be false.
>
> Cheers
> Pieter
>
> On 01/09/2015 21:55, David Robinson wrote:
> > Hi Pieter,
> >
> > Thank you for the response.
> >
> > Checked and unchecked exceptions in Java certainly have created
> interesting
> > discussions, but unchecked exceptions are intended for unexpected
> > conditions.
> >
> > Maybe the TP code should not throw an exception, but since it does, it
> > should
> > be a checked exception.
> >
> > isPresent() is a nice suggestion, however, it also throws a
> > RunTimeException.
> > So I hope if you are using isPresent() you are at least catching
> > RunTimeExceptions
> > as a guard.
> >
> > Consider the following Java code:
> >
> > try {
> > Graph graph = TinkerGraph.open();
> >
> > Vertex v1 = graph.addVertex("name", "value1", "name", "value2");
> >
> > v1.property("name").isPresent();
> > }
> > catch (Exception e) {
> > e.printStackTrace();
> > }
> >
> > This code will throw this exception:
> >
> > java.lang.IllegalStateException: Multiple properties exist for the
> provided
> > key, use Vertex.properties(name)
> > ..........
> >
> > which is also a RunTimeException:
> >
> https://docs.oracle.com/javase/8/docs/api/java/lang/IllegalStateException.html
> >
> > If you read the text for IllegalStateException, this does not appear to
> be
> > an appropriate use of this exception:
> >>> Signals that a method has been invoked at an illegal or inappropriate
> > time. In other words, the Java environment or Java >> application is not
> in
> > an appropriate state for the requested operation.
> >
> > The example raises another point around the difficulty of retrieving
> > multi-properties right now -but that
> > is for a different thread.
> >
> >
> > On Tue, Sep 1, 2015 at 2:16 PM, pieter-gmail <pi...@gmail.com>
> > wrote:
> >
> >> That exception has kinda gotten me to always first get the property then
> >> check isPresent()
> >>
> >> But no, I would not want any checked exceptions. In some circles that is
> >> also considered bad practice.
> >>
> >> Cheers
> >> Pieter
> >>
> >>
> >>
> >> On 01/09/2015 20:00, David Robinson wrote:
> >>> In Element.java (org.apache.tinkerpop.gremlin.structure.Element.java)
> >>> the value(...) method throws NoSuchElementException:
> >>>
> >>>
> >>> * @throws NoSuchElementException if the property does not exist on
> >> the
> >>> {@code Element}.
> >>> */
> >>> public default <V> V value(final String key) throws
> >>> NoSuchElementException {
> >>>
> >>>
> >>>
> >>> NoSuchElementException extends RunTimeException which is a unchecked
> >>> exception.
> >>>
> >>> Since this is an unchecked exception, the compiler does not force code
> >>> doing a v.value() to catch an exception, which can lead to nasty
> results.
> >>>
> >>> In some Java circles, it is considered bad practice to catch
> >>> RunTimeExceptions anyway.
> >>>
> >>> Should the exception thrown be changed to a checked exception -
> something
> >>> like "ValueDoesNotExist" that extends Exception ? This would become a
> >>> checked exception and will lead to better code based on TP 3.1.0
> >>>
> >>> Another alternative is for the value() method to simply return null (it
> >>> might have done this in TP 2.x ?) or change the signature of the
> value()
> >>> method so that a default value is supplied: value('key",
> >>> "default-if-not-set").
> >>>
> >>> Sounds like JIRA to me, but I wanted to see other's thoughts first.
> >>>
> >>> Thanks,
> >>>
> >>
>
>
Re: Vertex.value throws (unchecked) RunTimeException
Posted by pieter-gmail <pi...@gmail.com>.
Hi,
I checked, neither Neo4jProperty nor TinkerProperty throws an exception
on isPresent()
@Override
public boolean isPresent() {
return null != this.value;
}
Your exception is coming from the Vertex, which means the isPresent()
check is useless to you.
I never use multi/meta properties but I do now get your point.
Probably in your case it should return a VertexProperty for which
isPresent will be false.
Cheers
Pieter
On 01/09/2015 21:55, David Robinson wrote:
> Hi Pieter,
>
> Thank you for the response.
>
> Checked and unchecked exceptions in Java certainly have created interesting
> discussions, but unchecked exceptions are intended for unexpected
> conditions.
>
> Maybe the TP code should not throw an exception, but since it does, it
> should
> be a checked exception.
>
> isPresent() is a nice suggestion, however, it also throws a
> RunTimeException.
> So I hope if you are using isPresent() you are at least catching
> RunTimeExceptions
> as a guard.
>
> Consider the following Java code:
>
> try {
> Graph graph = TinkerGraph.open();
>
> Vertex v1 = graph.addVertex("name", "value1", "name", "value2");
>
> v1.property("name").isPresent();
> }
> catch (Exception e) {
> e.printStackTrace();
> }
>
> This code will throw this exception:
>
> java.lang.IllegalStateException: Multiple properties exist for the provided
> key, use Vertex.properties(name)
> ..........
>
> which is also a RunTimeException:
> https://docs.oracle.com/javase/8/docs/api/java/lang/IllegalStateException.html
>
> If you read the text for IllegalStateException, this does not appear to be
> an appropriate use of this exception:
>>> Signals that a method has been invoked at an illegal or inappropriate
> time. In other words, the Java environment or Java >> application is not in
> an appropriate state for the requested operation.
>
> The example raises another point around the difficulty of retrieving
> multi-properties right now -but that
> is for a different thread.
>
>
> On Tue, Sep 1, 2015 at 2:16 PM, pieter-gmail <pi...@gmail.com>
> wrote:
>
>> That exception has kinda gotten me to always first get the property then
>> check isPresent()
>>
>> But no, I would not want any checked exceptions. In some circles that is
>> also considered bad practice.
>>
>> Cheers
>> Pieter
>>
>>
>>
>> On 01/09/2015 20:00, David Robinson wrote:
>>> In Element.java (org.apache.tinkerpop.gremlin.structure.Element.java)
>>> the value(...) method throws NoSuchElementException:
>>>
>>>
>>> * @throws NoSuchElementException if the property does not exist on
>> the
>>> {@code Element}.
>>> */
>>> public default <V> V value(final String key) throws
>>> NoSuchElementException {
>>>
>>>
>>>
>>> NoSuchElementException extends RunTimeException which is a unchecked
>>> exception.
>>>
>>> Since this is an unchecked exception, the compiler does not force code
>>> doing a v.value() to catch an exception, which can lead to nasty results.
>>>
>>> In some Java circles, it is considered bad practice to catch
>>> RunTimeExceptions anyway.
>>>
>>> Should the exception thrown be changed to a checked exception - something
>>> like "ValueDoesNotExist" that extends Exception ? This would become a
>>> checked exception and will lead to better code based on TP 3.1.0
>>>
>>> Another alternative is for the value() method to simply return null (it
>>> might have done this in TP 2.x ?) or change the signature of the value()
>>> method so that a default value is supplied: value('key",
>>> "default-if-not-set").
>>>
>>> Sounds like JIRA to me, but I wanted to see other's thoughts first.
>>>
>>> Thanks,
>>>
>>
Re: Vertex.value throws (unchecked) RunTimeException
Posted by David Robinson <dr...@gmail.com>.
Hi Pieter,
Thank you for the response.
Checked and unchecked exceptions in Java certainly have created interesting
discussions, but unchecked exceptions are intended for unexpected
conditions.
Maybe the TP code should not throw an exception, but since it does, it
should
be a checked exception.
isPresent() is a nice suggestion, however, it also throws a
RunTimeException.
So I hope if you are using isPresent() you are at least catching
RunTimeExceptions
as a guard.
Consider the following Java code:
try {
Graph graph = TinkerGraph.open();
Vertex v1 = graph.addVertex("name", "value1", "name", "value2");
v1.property("name").isPresent();
}
catch (Exception e) {
e.printStackTrace();
}
This code will throw this exception:
java.lang.IllegalStateException: Multiple properties exist for the provided
key, use Vertex.properties(name)
..........
which is also a RunTimeException:
https://docs.oracle.com/javase/8/docs/api/java/lang/IllegalStateException.html
If you read the text for IllegalStateException, this does not appear to be
an appropriate use of this exception:
>> Signals that a method has been invoked at an illegal or inappropriate
time. In other words, the Java environment or Java >> application is not in
an appropriate state for the requested operation.
The example raises another point around the difficulty of retrieving
multi-properties right now -but that
is for a different thread.
On Tue, Sep 1, 2015 at 2:16 PM, pieter-gmail <pi...@gmail.com>
wrote:
> That exception has kinda gotten me to always first get the property then
> check isPresent()
>
> But no, I would not want any checked exceptions. In some circles that is
> also considered bad practice.
>
> Cheers
> Pieter
>
>
>
> On 01/09/2015 20:00, David Robinson wrote:
> > In Element.java (org.apache.tinkerpop.gremlin.structure.Element.java)
> > the value(...) method throws NoSuchElementException:
> >
> >
> > * @throws NoSuchElementException if the property does not exist on
> the
> > {@code Element}.
> > */
> > public default <V> V value(final String key) throws
> > NoSuchElementException {
> >
> >
> >
> > NoSuchElementException extends RunTimeException which is a unchecked
> > exception.
> >
> > Since this is an unchecked exception, the compiler does not force code
> > doing a v.value() to catch an exception, which can lead to nasty results.
> >
> > In some Java circles, it is considered bad practice to catch
> > RunTimeExceptions anyway.
> >
> > Should the exception thrown be changed to a checked exception - something
> > like "ValueDoesNotExist" that extends Exception ? This would become a
> > checked exception and will lead to better code based on TP 3.1.0
> >
> > Another alternative is for the value() method to simply return null (it
> > might have done this in TP 2.x ?) or change the signature of the value()
> > method so that a default value is supplied: value('key",
> > "default-if-not-set").
> >
> > Sounds like JIRA to me, but I wanted to see other's thoughts first.
> >
> > Thanks,
> >
>
>
Re: Vertex.value throws (unchecked) RunTimeException
Posted by pieter-gmail <pi...@gmail.com>.
That exception has kinda gotten me to always first get the property then
check isPresent()
But no, I would not want any checked exceptions. In some circles that is
also considered bad practice.
Cheers
Pieter
On 01/09/2015 20:00, David Robinson wrote:
> In Element.java (org.apache.tinkerpop.gremlin.structure.Element.java)
> the value(...) method throws NoSuchElementException:
>
>
> * @throws NoSuchElementException if the property does not exist on the
> {@code Element}.
> */
> public default <V> V value(final String key) throws
> NoSuchElementException {
>
>
>
> NoSuchElementException extends RunTimeException which is a unchecked
> exception.
>
> Since this is an unchecked exception, the compiler does not force code
> doing a v.value() to catch an exception, which can lead to nasty results.
>
> In some Java circles, it is considered bad practice to catch
> RunTimeExceptions anyway.
>
> Should the exception thrown be changed to a checked exception - something
> like "ValueDoesNotExist" that extends Exception ? This would become a
> checked exception and will lead to better code based on TP 3.1.0
>
> Another alternative is for the value() method to simply return null (it
> might have done this in TP 2.x ?) or change the signature of the value()
> method so that a default value is supplied: value('key",
> "default-if-not-set").
>
> Sounds like JIRA to me, but I wanted to see other's thoughts first.
>
> Thanks,
>