Back to the main page.

Bug 3336 - get rid of confusing stack trace of ft_errror

Reported 2017-08-24 08:45:00 +0200
Modified 2019-08-10 12:37:17 +0200
Product: FieldTrip
Component: core
Version: unspecified
Hardware: PC
Operating System: Mac OS
Importance: P5 normal
Assigned to:
Depends on:
See also:

Robert Oostenveld - 2017-08-24 08:45:23 +0200

The stack trace is important in error messages, and ft_error makes it rather confusing by adding ft_error and ft_notification to the stack. Except for the automatic messageId, there is nothing that makes ft_error better than a normal error. For ft_warning the "once" functionality makes it valuable. The messageId can be maintained by moving that from ft_notification to a stand-alone function.

Robert Oostenveld - 2017-08-24 09:00:59 +0200

[bug3336-ft_error 043d2ab] implemented defaultId separate from ft_notification, removed ft_error and ft_warning from engine and peer (just like qsub), added ft_warning/ft_notification more consistently to all private directories. See

Robert Oostenveld - 2017-08-24 12:46:36 +0200

I merged There were some issues with synchronizing defaultId, so I had to do some additional commits later on (which did not go through a PR). qsub, peer and engine are now all clean.

Robert Oostenveld - 2017-08-24 13:01:38 +0200

the private/defaultId helper function now seems to work correctly. That means that ft_error(msg) can be replaced by error(defaultId, msg). The following works as expected in both cases ------- function test_error subfunction function subfunction % ft_error('something went wrong'); error(defaultId, 'something went wrong'); -------

Stephen Whitmarsh - 2017-09-25 14:01:19 +0200

This might have introduced the error I just reported:

Robert Oostenveld - 2018-11-27 15:28:34 +0100

I had a branch bug3335 that included a final commit with a search-and-replace of ft_error(...) into error(defaultId,..). That final commit was stale and would not merge any more. Hence I have just deleted it. I think it should be possible to solve this more elegantly using a trimmed stack. That would not only work for error, but also for warning and (possibly) the other notification levels with a backtrace.

Robert Oostenveld - 2018-11-27 17:08:23 +0100

Just discussed this with JM on the phone. The outcome was that there should be some better way of doing it... I searched and found this in the code % remove this function itself and the ft_xxx calling function stack = stack(3:end);

Robert Oostenveld - 2018-11-27 17:23:27 +0100

this has been resolved in Please reopen if you are still confused by the error messages.

Robert Oostenveld - 2019-08-10 12:37:17 +0200

This closes a whole series of bugs that have been resolved (either FIXED/WONTFIX/INVALID) for quite some time. If you disagree, please file a new issue on