java exception handling

java-programmer, java exception handling i was arguing with my manager about whether it's better to throw
exception from a service that im developing or to give the user
returned value. My supporting points are:
1-thowing exception is much mostly than returned value in term of
performance.
2-in returned value way the user can customize the behavior of the
system as he like and he would have clear view of the service result.
3-with respect to the user requirement he doesn't really need a
returned value or exception from
the service.
my manager supporting points:
1-the service should be general so in future if somebody want to be
informed by the result of
the service we don't have to modify it.
but infact if we consider all the assumption we will delf into hunders
of assumptions and if this is nessary the returned value is better way
than throwing exception.

im very sorry for my long plah plah plah

any one have a comment.

Note: code in java

java-programmer >> java exception handling polaris wrote:
> i was arguing with my manager about whether it's better to throw
> exception from a service that im developing or to give the user
> returned value. My supporting points are:
> 1-thowing exception is much mostly than returned value in term of
> performance.
> 2-in returned value way the user can customize the behavior of the
> system as he like and he would have clear view of the service result.
> 3-with respect to the user requirement he doesn't really need a
> returned value or exception from
> the service.
> my manager supporting points:
> 1-the service should be general so in future if somebody want to be
> informed by the result of
> the service we don't have to modify it.
> but infact if we consider all the assumption we will delf into hunders
> of assumptions and if this is nessary the returned value is better way
> than throwing exception.

I think exceptions has a couple of advantages over return value
error indication:

1) You can force the programmer to deal with it by making
the exception checked.

2) If the exception is not to be handled by the calling method,
then exceptions is much easier to get bubbling up through the
call stack than return values.

And performance should not be a problem. Exceptions should be
an exception ! :-)

Arne

java-programmer >> java exception handling polaris wrote:
> i was arguing with my manager about whether it's better to throw
> exception from a service that im developing or to give the user
> returned value. My supporting points are:
> 1-thowing exception is much mostly than returned value in term of
> performance.

The impact of try-catch blocks when they are not used has become
negligible and the performance impact is not terrible when they are
used. But any performance gained is on the order of several machine
cycles, which is not enough to impact such a major architecture decision.

> 2-in returned value way the user can customize the behavior of the
> system as he like and he would have clear view of the service result.

But values may be in imperfect states. A lazy user might not realize
that failures could happen and important code could blow up in his face.

> 3-with respect to the user requirement he doesn't really need a
> returned value or exception from
> the service.

If something is wrong, he needs to know. Period, full stop, end of story.

> my manager supporting points:
> 1-the service should be general so in future if somebody want to be
> informed by the result of
> the service we don't have to modify it.
> but infact if we consider all the assumption we will delf into hunders
> of assumptions and if this is nessary the returned value is better way
> than throwing exception.

How so? I sense some C or C++ assumptions coming into play here.

2. An exception can force the user to deal with the error. The user is
often in the best seat to decide whether or not he should repair the
situation or forcibly terminate.

3. Exceptions can provide finer granularity control over errors. Imagine
if Class.getMethod simply returned null instead of throwing an
exception. It would be difficult to tell if it was because the method
didn't exist or if it was merely insufficient access, the difference
between which may be important.

4. Hijacking the return values makes chaining operations difficult.
Class.forName(className).getMethod(name, args); is a somewhat common
idiom for code needing reflection. Should forName return null on error,
I would have to check for nullity first.

You also have not fully described what the circumstances are. In
general, the Java API often provides a good role model to follow. The
only times where it uses return values is where failure is not
exceptional, e.g., adding a method to a Set.

> im very sorry for my long plah plah plah

The proper term I believe is "pontification."

> any one have a comment.

One nit: try to use some more capitalization and spacing between
paragraphs. It's easier on eyes.

--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth

java-programmer >> java exception handling Joshua Cranmer wrote:
> [several good arguments for exceptions]
...
> You also have not fully described what the circumstances are. In
> general, the Java API often provides a good role model to follow. The
> only times where it uses return values is where failure is not
> exceptional, e.g., adding a method to a Set.

Joshua shows that exceptions are often, but not always, the best idiom for
things that seem to go either way.

Stepping back, Joshua's excellent advice is rooted in a perspective that
distinguishes "in-line" returns from "out-of-line" conditions that belong to
exceptions.

This part of domain analysis is fuzzy at times, no question. What really is
an "in-line" result in the problem domain?

One must factor predictions of which idiom will prove more troublesome to
maintain in the future. Notice that Joshua's answer is also grounded in the
notion of operational usefulness - what mechanism makes it easier to keep a
system running in the field?

There is a conceptual ground and a pragmatic basis that both argue for his
conclusions.

The consideration of future use is the hardest but also most important part of
planning an architecture. With a Really Useful Application, the operational
phase is the longest and most critical part of the life cycle.

--
Lew

java-programmer >> java exception handling On 1 礓琼? 18:53, Joshua Cranmer <email***@***.com> wrote:
> polaris wrote:
> > i was arguing with my manager about whether it's better to throw
> > exception from a service that im developing or to give the user
> > returned value. My supporting points are:
> > 1-thowing exception is much mostly than returned value in term of
> > performance.
>
> The impact of try-catch blocks when they are not used has become
> negligible and the performance impact is not terrible when they are
> used. But any performance gained is on the order of several machine
> cycles, which is not enough to impact such a major architecture decision.
>
> > 2-in returned value way the user can customize the behavior of the
> > system as he like and he 爓ould have clear view of the service result.
>
> But values may be in imperfect states. A lazy user might not realize
> that failures could happen and important code could blow up in his face.
>
> > 3-with respect to the user requirement he doesn't really need a
> > returned value or exception from
> > the service.
>
> If something is wrong, he needs to know. Period, full stop, end of story.
>
> > my manager supporting points:
> > 1-the service should be general so in future if somebody want to be
> > informed by the result of
> > 爐he service we don't have to modify it.
> > but infact if we consider all the assumption we will delf into hunders
> > of assumptions and if this is nessary the returned value is better way
> > than throwing exception.
>
> How so? I sense some C or C++ assumptions coming into play here.
>
> 2. An exception can force the user to deal with the error. The user is
> often in the best seat to decide whether or not he should repair the
> situation or forcibly terminate.
>
> 3. Exceptions can provide finer granularity control over errors. Imagine
> if Class.getMethod simply returned null instead of throwing an
> exception. It would be difficult to tell if it was because the method
> didn't exist or if it was merely insufficient access, the difference
> between which may be important.
>
> 4. Hijacking the return values makes chaining operations difficult.
> Class.forName(className).getMethod(name, args); is a somewhat common
> idiom for code needing reflection. Should forName return null on error,
> I would have to check for nullity first.
>
> You also have not fully described what the circumstances are. In
> general, the Java API often provides a good role model to follow. The
> only times where it uses return values is where failure is not
> exceptional, e.g., adding a method to a Set.
>
> > im very sorry for my long plah plah plah
>
> The proper term I believe is "pontification."
>
> > any one have a comment.
>
> One nit: try to use some more capitalization and spacing between
> paragraphs. It's easier on eyes.
>
> --
> Beware of bugs in the above code; I have only proved it correct, not
> tried it. -- Donald E. Knuth

ok I agree with you Arne and Joshua that exception forces the
programmer to deal with the result but one thing I have to clarify, is
that this services is provided to a department where they don't
really care about the result of this service at business level. In
fact it concerns the service provider himself who needs to know when
some action is happening in the this department to perform some action
useful for him.

Anther thing i have to mention is that we have more than 1700 expected
daily transactions on this service so we may give the performance
factor more attention even its negligible at the level of single
transaction.

exception involves extra code and processing while in reality we don't
need even any returned
value from the service.

alot of Thanks for u.

java-programmer >> java exception handling On 1 賷賳丕賷乇, 18:14, Arne Vajh酶j <email***@***.com> wrote:
> polaris wrote:
> > i was arguing with my manager about whether it's better to throw
> > exception from a service that im developing or to give the user
> > returned value. My supporting points are:
> > 1-thowing exception is much mostly than returned value in term of
> > performance.
> > 2-in returned value way the user can customize the behavior of the
> > system as he like and he 聽would have clear view of the service result.
> > 3-with respect to the user requirement he doesn't really need a
> > returned value or exception from
> > the service.
> > my manager supporting points:
> > 1-the service should be general so in future if somebody want to be
> > informed by the result of
> > 聽the service we don't have to modify it.
> > but infact if we consider all the assumption we will delf into hunders
> > of assumptions and if this is nessary the returned value is better way
> > than throwing exception.
>
> I think exceptions has a couple of advantages over return value
> error indication:
>
> 1) You can force the programmer to deal with it by making
> 聽聽 the exception checked.
>
> 2) If the exception is not to be handled by the calling method,
> 聽聽 then exceptions is much easier to get bubbling up through the
> 聽聽 call stack than return values.
>
> And performance should not be a problem. Exceptions should be
> an exception ! 聽:-)
>
> Arne- 廿禺賮丕亍丕賱賳氐丕賱賲賯鬲亘爻 -
>
> - 毓乇囟丕賱賳氐丕賱賲賯鬲亘爻 -

java-programmer >> java exception handling polaris wrote:
> ok I agree with you Arne and Joshua that exception forces the
> programmer to deal with the result but one thing I have to clarify, is
> that this services is provided to a department where they don't
> really care about the result of this service at business level. In
> fact it concerns the service provider himself who needs to know when
> some action is happening in the this department to perform some action
> useful for him.

How does this affect the issue of whether to use exceptions?

> Anther thing i have to mention is that we have more than 1700 expected
> daily transactions on this service so we may give the performance
> factor more attention even its negligible at the level of single
> transaction.

How does this affect the issue of whether to use exceptions?

> exception involves extra code and processing while in reality we don't
> need even any returned
> value from the service.

How does this affect the issue of whether to use exceptions?

Exceptions are not "extra" code. "Extra" code is code not needed. Exceptions
are code that is needed. Therefore, not "extra".

What is this laziness on the part of programmers, that they do not wish to
code the logic the problem at hand requires?

Correctly used, exceptions help the programmer of the application. They
aren't there to help the user, except indirectly in that the user will never
see the crashes prevented by the use of exceptions.

So the question with exceptions is whether you want to prevent the user from
experiencing program crashes. If you do wish to prevent the user from
experiencing program crashes, then exceptions are a powerful tool for that.

--
Lew

java-programmer >> java exception handling polaris wrote:
> On 1 賷賳丕賷乇, 18:14, Arne Vajh酶j <email***@***.com> wrote:
>> And performance should not be a problem. Exceptions should be
>> an exception ! :-)
>>
>> Arne- 廿禺賮丕亍丕賱賳氐丕賱賲賯鬲亘爻 -
>>
>> - 毓乇囟丕賱賳氐丕賱賲賯鬲亘爻 -
>

Say what ?

Arne

java-programmer >> java exception handling polaris wrote:
> ok I agree with you Arne and Joshua that exception forces the
> programmer to deal with the result but one thing I have to clarify, is
> that this services is provided to a department where they don't
> really care about the result of this service at business level. In
> fact it concerns the service provider himself who needs to know when
> some action is happening in the this department to perform some action
> useful for him.

Does not change anything.

> Anther thing i have to mention is that we have more than 1700 expected
> daily transactions on this service so we may give the performance
> factor more attention even its negligible at the level of single
> transaction.

1700 daily transactions is absolutely nothing when we talk overhead
of exceptions.

If we assume that 1 million exceptions per second is 100% load, then
1700 exceptions per day is approx. 0.000002% extra load.

I think you can live with that.

> exception involves extra code and processing while in reality we don't
> need even any returned
> value from the service.

I think you need it.

Arne

java-programmer >> java exception handling Arne Vajh酶j wrote :
> polaris wrote:
>> On 1 賷賳丕賷乇, 18:14, Arne Vajh酶j <email***@***.com> wrote:
>>> And performance should not be a problem. Exceptions should be
>>> an exception ! :-)
>>>
>>> Arne- 廿禺賮丕亍丕賱賳氐丕賱賲賯鬲亘爻 -
>>>
>>> - 毓乇囟丕賱賳氐丕賱賲賯鬲亘爻 -
>>
>
> Say what ?
>
> Arne

That would be:

what say

--
Wojtek :-)

java-programmer >> java exception handling On Tue, 1 Jan 2008 03:30:42 -0800 (PST), polaris
<email***@***.com> wrote, quoted or indirectly quoted someone who
said :

>any one have a comment

See http://mindprod.com/jgloss/exception.html#STATUSCODE

It should be uploaded within about 15 minutes.

--
Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com

java-programmer >> java exception handling On 3 礓琼? 11:31, Roedy Green <email***@***.com>
wrote:
> On Tue, 1 Jan 2008 03:30:42 -0800 (PST), polaris
> <email***@***.com> wrote, quoted or indirectly quoted someone who
> said :
>
> >any one have a comment
>
> Seehttp://mindprod.com/jgloss/exception.html#STATUSCODE
>
> It should be uploaded within about 15 minutes.
>
> --
> Roedy Green Canadian Mind Products
> The Java Glossaryhttp://mindprod.com

ok thank you for everybody by his name contributed under this thread I
got the idea now.

The idea I got is that with respect to our service nature where it
should throw an exception
if it doesn't find any related record for the input values in DB.

Actually this the common case for all the 1700 service call. At most
may be there are 10 of 1700 cases where it finds records corresponding
to the input values and therefore it won't throw exception.

As I conclude from the following statement in Roedy link
http://mindprod.com/jgloss/exception.html#STATUSCODE
Exceptions should be exceptional. If there are 50/50 odds of either
status, you should use a status code. There is an extra overhead to
catching an exception.
It's better to use status code for our case.
and this is what Arne said as well.

java-programmer >> java exception handling On Thu, 3 Jan 2008 11:28:32 -0800 (PST), polaris
<email***@***.com> wrote, quoted or indirectly quoted someone who
said :

>As I conclude from the following statement in Roedy link
>http://mindprod.com/jgloss/exception.html#STATUSCODE
>Exceptions should be exceptional. If there are 50/50 odds of either
>status, you should use a status code. There is an extra overhead to
>catching an exception.
>It's better to use status code for our case.
>and this is what Arne said as well.

I have revised that paragraph to read:

Should you report problems with a status code returned from a method
or with an Exception? The C-style is to use status codes.

There is nothing that says the caller has check a status code.
Programmers are lazy and don't bother to check return codes. No error
or warning is generated.

If the caller of the caller is the proper place to handle the
exception it takes futzing to propagate the information up the chain.

Exceptions should be exceptional. They are for errors, things that
are not supposed happen. EOFException is a special case. It will
happen at most once per file. If there are 50/50 odds of either
status, you should use a status code. There is an extra overhead to
catching an exception. Don't use Exceptions to return common place
data or status. A rule of thumb might be if a method returns an error
more often than 1 in 10, use a status code instead of an Exception to
report the problem.

--
Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com