Wireshark · Wireshark-dev: Re: [Wireshark-dev] SVN #25615: "Wiretap code probably shouldn't abort the application either."

[Guy Harris <guy@xxxxxxxxxxxx>]

On Jul 17, 2008, at 3:00 PM, Bill Meier wrote:

> My understanding of the replies is that the current usage of g_error &
> g_assert in wiretap files is OK.

Well, maybe.

The problem is that we don't want to have any wiretap code to abort or  
exit if it finds something in the capture file that it doesn't like;  
however, it's not necessarily a problem if it aborts if it detects an  
internal inconsistency.  Unfortunately, checkAPIs can't tell the  
difference between those two cases.

Perhaps, as per my mail, we need to have an "internal error" return,  
so that wiretap doesn't abort for internal inconsistencies  
(programming errors), but the application can tell the user that an  
internal error happened and they should report it to the application  
developer (which would be the Wireshark developers for Wireshark/ 
TShark/capinfos/editcap/etc.).  That's how we handle it for dissectors  
- there are macros for reporting dissector bugs, which don't cause  
Wireshark/TShark to exit, but they do cause an error to be reported in  
the protocol tree, so the user will see a "dissector bug" indication  
in the packet details.