Ethereal-dev: Re: [Ethereal-dev] Throwing ReportedBoundsError to report errors other than "the
Guy Harris wrote:
In some dissectors, errors in packets are reported by explicitly
throwing ReportedBoundsError.
That does, in most cases, cause a "Malformed packet" error, but, in
some cases (if "pinfo->fragmented" is set), might cause an
"Unreassembled packet" error instead. (The packet might be too short
because it really *is* too short, i.e. whatever put it on the wire
didn't put everything out; it might also be too short because it had
to go into more than one link-layer frame, and the option to do
reassembly wasn't done.)
I was recently stumbled over this message (before I fixed the
reassembling in the DCE/RPC dissector some days ago). I had some trouble
finding the real problem until I stepped through the code and jumped
unexpectedly caused by an exception :-)
I was thinking about (at least) change that message to make it more
clear that it's caused by an exception, maybe something like: [Malformed
data while reassembling]. Although I'm still not really happy with this.
That error doesn't give details of the problem with the packet.
Should we have a separate exception for those types of packet errors -
one for which we use THROW_MESSAGE(), with the message giving an
explicit description of the problem with the packet?
Having a meaningful message in these kind of problems seems to be a good
idea :-)
AFAIK, while reassembling, the errors could also come from the usual
functions e.g. tvb_get ... (or am I wrong with this assumption?). So we
would get two different Errors to handle these errors while
reassembling, the common functions and the special places you mentioned
above, containing some more detailed info.
I'm not sure if using a different Error for this is really useful then.
However, adding some more info using THROW_MESSAGE() at that special
places you'd mentioned seems to be a good idea.
Getting the real problem if reassembling fails usually involves calling
the MSVC debugger for me to track the problems down. So improving this
seems to be a very good idea regardless of which way we will go...
Regards, ULFL
