Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.java.programmer > #32434 > unrolled thread

What to do with an exception of Field.get()

Started byCecil Westerhof <Cecil@decebal.nl>
First post2015-08-28 15:37 +0200
Last post2015-08-28 16:52 +0200
Articles 5 — 3 participants

Back to article view | Back to comp.lang.java.programmer


Contents

  What to do with an exception of Field.get() Cecil Westerhof <Cecil@decebal.nl> - 2015-08-28 15:37 +0200
    Re: What to do with an exception of Field.get() Cecil Westerhof <Cecil@decebal.nl> - 2015-08-28 16:22 +0200
      Re: What to do with an exception of Field.get() Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-08-28 10:44 -0400
        Re: What to do with an exception of Field.get() Tassilo Horn <tsdh@gnu.org> - 2015-08-28 16:57 +0200
      Re: What to do with an exception of Field.get() Tassilo Horn <tsdh@gnu.org> - 2015-08-28 16:52 +0200

#32434 — What to do with an exception of Field.get()

FromCecil Westerhof <Cecil@decebal.nl>
Date2015-08-28 15:37 +0200
SubjectWhat to do with an exception of Field.get()
Message-ID<87fv33fsa6.fsf@Equus.decebal.nl>
I am using:
    http://docs.oracle.com/javase/7/docs/api/java/lang/reflect/Field.html#get%28java.lang.Object%29

This can throw an IllegalArgumentException, or an
IllegalAccessException.

I see this as an unacceptable error and I am thinking about giving a
stacktrace and exiting the program.

Is this acceptable, or is it not done?

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

[toc] | [next] | [standalone]


#32435

FromCecil Westerhof <Cecil@decebal.nl>
Date2015-08-28 16:22 +0200
Message-ID<87bndrfq7c.fsf@Equus.decebal.nl>
In reply to#32434
On Friday 28 Aug 2015 15:37 CEST, Cecil Westerhof wrote:

> I am using:
> http://docs.oracle.com/javase/7/docs/api/java/lang/reflect/Field.html#get%28java.lang.Object%29
>
> This can throw an IllegalArgumentException, or an
> IllegalAccessException.
>
> I see this as an unacceptable error and I am thinking about giving a
> stacktrace and exiting the program.
>
> Is this acceptable, or is it not done?

Answering my own question. ;-)

In principle you never know where your function is used. (If you share
it.) So I wrote a custom exception (which gives a stacktrace). In this
way the user only has to check for one exception (it is used in Java
6) and can decide what to do.

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

[toc] | [prev] | [next] | [standalone]


#32436

FromEric Sosman <esosman@comcast-dot-net.invalid>
Date2015-08-28 10:44 -0400
Message-ID<mrps1v$494$1@dont-email.me>
In reply to#32435
On 8/28/2015 10:22 AM, Cecil Westerhof wrote:
> On Friday 28 Aug 2015 15:37 CEST, Cecil Westerhof wrote:
>
>> I am using:
>> http://docs.oracle.com/javase/7/docs/api/java/lang/reflect/Field.html#get%28java.lang.Object%29
>>
>> This can throw an IllegalArgumentException, or an
>> IllegalAccessException.
>>
>> I see this as an unacceptable error and I am thinking about giving a
>> stacktrace and exiting the program.
>>
>> Is this acceptable, or is it not done?
>
> Answering my own question. ;-)
>
> In principle you never know where your function is used. (If you share
> it.) So I wrote a custom exception (which gives a stacktrace). In this
> way the user only has to check for one exception (it is used in Java
> 6) and can decide what to do.

     That seems the right approach.  If you haven't done so already,
it's a good idea to propagate the original exception as the "cause"
of the one eventually thrown:

	try {
	    ...
	} catch (IllegalArgumentException | IllegalAccessException ex) {
	    throw new WrapperException("Yikes!", ex);
	}

or (if the wrapping exception lacks a suitable constructor):

	try {
	   ...
	} catch (IllegalArgumentException | IllegalAccessException ex) {
	    Exception wrapper = new WrapperException("Yikes!");
	    wrapper.initCause(ex);
	    throw wrapper;
	}

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

[toc] | [prev] | [next] | [standalone]


#32438

FromTassilo Horn <tsdh@gnu.org>
Date2015-08-28 16:57 +0200
Message-ID<874mjj8nqu.fsf@gnu.org>
In reply to#32436
Eric Sosman <esosman@comcast-dot-net.invalid> writes:

>> In principle you never know where your function is used. (If you share
>> it.) So I wrote a custom exception (which gives a stacktrace). In this
>> way the user only has to check for one exception (it is used in Java
>> 6) and can decide what to do.
>
>     That seems the right approach.  If you haven't done so already,
> it's a good idea to propagate the original exception as the "cause"
> of the one eventually thrown:
>
> 	try {
> 	    ...
> 	} catch (IllegalArgumentException | IllegalAccessException ex) {
> 	    throw new WrapperException("Yikes!", ex);
> 	}

Catching exceptions of multiple types with one catch clause is only
supported as of Java 7, I think.

Bye,
Tassilo

[toc] | [prev] | [next] | [standalone]


#32437

FromTassilo Horn <tsdh@gnu.org>
Date2015-08-28 16:52 +0200
Message-ID<878u8v8nyi.fsf@gnu.org>
In reply to#32435
Cecil Westerhof <Cecil@decebal.nl> writes:

>> I am using:
>> http://docs.oracle.com/javase/7/docs/api/java/lang/reflect/Field.html#get%28java.lang.Object%29
>>
>> This can throw an IllegalArgumentException, or an
>> IllegalAccessException.
>>
>> I see this as an unacceptable error and I am thinking about giving a
>> stacktrace and exiting the program.
>>
>> Is this acceptable, or is it not done?
>
> Answering my own question. ;-)
>
> In principle you never know where your function is used. (If you share
> it.) So I wrote a custom exception (which gives a stacktrace).

You can get a stack trace of every exception.

> In this way the user only has to check for one exception (it is used
> in Java 6) and can decide what to do.

That wouldn't be different if you didn't handle the exception at all and
just declared to throw the same exceptions as Field.get().  Then the
user of your method could either have one `catch (Exception e)' clause
or multiple clauses catching the exceptions which they can handle.

Well, in case your custom exception class derives from RuntimeException
the user is free not to handle the exceptions at all whereas he would
need to handle at least the IllegalAccessException otherwise.  I
wouldn't argue that this is a good thing...

Bye,
Tassilo

[toc] | [prev] | [standalone]


Back to top | Article view | comp.lang.java.programmer


csiph-web