«

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

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

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

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

On 1 íäÇíÑ, 18:53, Joshua Cranmer <Pidgeo...@verizon.invalid> 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 *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

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.

On 1 يناير, 18:14, Arne Vajhøj <a...@vajhoej.dk> 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- إخ�اء النص المقتبس -
>
> - عرض النص المقتبس -

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

polaris wrote:
> On 1 يناير, 18:14, Arne Vajhøj <a...@vajhoej.dk> wrote:
>> And performance should not be a problem. Exceptions should be
>> an exception !
>>
>> Arne- إخ�اء النص المقتبس -
>>
>> - عرض النص المقتبس -
>

Say what ?

Arne

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

Arne Vajhøj wrote :
> polaris wrote:
>> On 1 يناير, 18:14, Arne Vajhøj <a...@vajhoej.dk> wrote:
>>> And performance should not be a problem. Exceptions should be
>>> an exception !
>>>
>>> Arne- إخ�اء النص المقتبس -
>>>
>>> - عرض النص المقتبس -
>>
>
> Say what ?
>
> Arne

That would be:

what say

--
Wojtek