Back to the main page.
Bug 1893 - Is there a standard format for warning IDs?
| Status | CLOSED FIXED |
| Reported | 2012-12-14 10:18:00 +0100 |
| Modified | 2019-08-10 12:03:30 +0200 |
| Product: | FieldTrip |
| Component: | core |
| Version: | unspecified |
| Hardware: | PC |
| Operating System: | Windows |
| Importance: | P3 normal |
| Assigned to: | |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | |
| See also: |
Bart Gips - 2012-12-14 10:18:47 +0100
In this particular case I want to add an ID to the warning in ft_read_event. If ft_read_event does not recognize the format it will display the warning: otherwise warning('unsupported event format (%s)', eventformat); event = []; However when reading neurosim data and defining trials with ft_trialfun_general it will also call ft_read_event, and therefore always give me this warning. I want to control for this by using warning('off',ID) function_X warning('on',ID) To do this I propose changing ft_read_event to something like: otherwise warning('FT:no_event','unsupported event format (%s)', eventformat); event = []; TL;DR: Question: Is there a standard FieldTrip format for warning IDs?
Robert Oostenveld - 2012-12-17 10:38:27 +0100
the "standard" is that we don't do warning IDs, which is not ideal of course. If we were to implement warning and error IDs, they would have to be unique throughout all code. The situation "no_event" might happen at multiple locations. I would also write out FT to FieldTrip. I suggest a scheme like FieldTrip:filename:description which in this case would become FieldTrip:ft_read_event:unsupported_event_format My choice here would be _not_ to use the module/directory name, so no FieldTrip:fileio:ft_read_event:unsupported_event_format because some functions reoccur at multiple locations and the directory organization might again change in the future.
Bart Gips - 2012-12-17 11:01:12 +0100
Agreed; I have used: FieldTrip:ft_read_event:unsupported_event_format. Using ft_read_data to read in neurosim spike data will no longer display the warning. I will close the bug. If someone wants to comment on the ID structure, then by all means reopen it.
Jörn M. Horschig - 2013-01-07 11:17:56 +0100
I'd propose to take that up in the next FT meeting to keep us all up to date about this ;) I like the idea