A warning 'channel' ?

Question

Hello.
Consider a method such as:ResultObject get(int requestSize){
} this method will attempt to service the request
and return a result who's size is 'requestSize'.
However, what if the the method could only provide half
the request?
We already have a 'channel' to provide information to the
caller if the method could not service the request at all, but
what if it can service the request, but only part.
In this case it might be nice to notify the caller that they could
not fully satisfy the request, but return the result anyway.
In the currently java world we can solve the problem in a few ways,
"ResultObject" could contain a field indicating if the request was
fully serviced, or the object the method is contained in could contain
some field like "getLastWarning()" indicating if a warning (i.e.
request not completely fulfilled) as available. or, the "get" method
could take a ResultObject as a param and set it's variable itself,
returning a result indicating how the method went (or even throwing
an exception mid-way through the setting). as we know, this is the
appoach taken by the java.io package.
Wouldn't it be nice, however, to be able to throw a "warning" back
to the client (along with the partly-filled RequestObject) notifying them
that only part of their request was filled.
something like:ResultObject get(int requestSize){
  ResultObject result = ...
  throw new Warning(result, "Could not fully satisfy request");
ResultObject res;
try {
  res = get(10);
} catch(Warning w){
  System.out.println("Warning: " + w);
// do things with res. of course, this code is ugly, and hopefully any solution wouldn't
be implement this way, (i mean, we could achieve could like this right
now by tacking on an "Object" to each Exception and then grabbing it
out once it's caught, but it feels ugly.
or is there some obvious, non-hack-like solution to this that I have missed?

Answer 1

In the case of some IO operation, say, when it runsout of
space and can't continue converting something; orany
number of situations ... im sure you can think of afew..?
So you didn't have a particular situation in mind?Well, my situation is practically identical to the InputStream.read(byte[]) situation :)
It is "atomic", the method only does "X", but itjust may ot
be able to fully complete "X" and hence have onlyhalf-x.
Umm.. x is not atomic if there can be "half x", it's
either all of x or none of x :)
I wanted setResources to do both X and Y, I solved the
problem by removing Y.Well, as is realised by my situation, there is no Y, it's really only
X, but X may not be completely satisfied. (byte array not completely filled).
Well sure, and I mentioned this in the OP, but it'ssort of hack-like
isn't it ? I mean, we are avoiding returning what wereally want to
return in place of a confirmation value. it's prettymuch equiv to returning
an error code in place of exceptions. all I wassuggesting is that perhaps
there could be a similar channel as Exceptions forWarnings (read != request)
and so on.
well, maybe there could be something, maybe there
could be somethign that let you return a value
and throw a 'warning' .. but with the current
toolset that's not possible. Sure, but maybe it could be changed ;) Not that I have much hope
of that happening ... however I am gathering a nice little list of features
that I would like in my own language :)
I disagree it is like
returning an error code instead of throwing an
exception; if a part of the task can be expected to
fail, exceptions should not be used. And what about
the caller, the caller may want to know what part of
the task failed; how many bytes could not be read,
which resources could not be booked, etc, using the
return value of a method seems most natural for
that..You lost me a bit here, I'm not sure if you misunderstood my previous
statement; let me clarify:
I meant returning an error code compared to exceptions is like returning
the number of bytes returned instead of a 'warning'. using the return value
to do something other then return a useful object is more procedural and c-like
rather then java-oo like.
the exception channel is great; if only we could get a warning channel
to accompany it, it would be complete :)
in your case returning the number of resources that could not be booked seems
logical if that is the point of the method. but if the method is design to return a
"BookingSchedule" or whatever it's a little strange to see the number of returned
books come back and the bookingSchedule filled out via a param, isn't it ? (not
sure if this is what you were suggesting, but this is the equiv implementation
the in.read() approach takes, of course).
the things mentioned so far are usually of
doX-nature and not of calculateX, the return value
wouldn't get used for other purpose.....in my situation, it is a "getX" based operation hence I must
return X, not a count indicating how far I could satisfy the request
for X. (i.e: to solve my problem I need to implement it in the form
of in.read() not the logical returning-the-result system).