* factor out error message functions, access function stack to know location
@ 2015-10-26 1:17 Emanuel Berg
0 siblings, 0 replies; 4+ messages in thread
From: Emanuel Berg @ 2015-10-26 1:17 UTC (permalink / raw)
To: help-gnu-emacs
In the sweet science of shell scripting, I wrote some
zsh the other day (that appears last in this post),
along with a couple of other functions that will cover
other typical error situations. [1]
The thought is to have uniform error messages so that
when a function for example doesn't get sufficient
input, or cannot verity it, as those situations are
common to many functions, an error function will be
called to print a stderr message, rather than to have
that coded over and over in all those functions.
Only problem is, in order for debugging to be much
less painful, the location where the problem happens
must still be known. In the below zsh, the first line
handles this by accessing the function stack - pretty
clever, ey?
Note: arrays in zsh are *not* zero-indexed, so the
first element of funcstack is funcstack[1] and that is
the current function! Ergo, funcstack[2] is the
function that called the error handler!
My question is, how do I do the same in Lisp (Elisp)?
The zsh:
no-file-msg () {
local fun=$funcstack[2]
local file=$1
echo "$fun: no such file: $file" >&2
}
[1] http://user.it.uu.se/~embe8573/conf/.zsh/error
--
underground experts united
http://user.it.uu.se/~embe8573
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: factor out error message functions, access function stack to know location
[not found] <mailman.1053.1445821696.7904.help-gnu-emacs@gnu.org>
@ 2015-10-26 2:42 ` Dan Espen
2015-10-27 0:27 ` Emanuel Berg
0 siblings, 1 reply; 4+ messages in thread
From: Dan Espen @ 2015-10-26 2:42 UTC (permalink / raw)
To: help-gnu-emacs
Emanuel Berg <embe8573@student.uu.se> writes:
> In the sweet science of shell scripting, I wrote some
> zsh the other day (that appears last in this post),
> along with a couple of other functions that will cover
> other typical error situations. [1]
>
> The thought is to have uniform error messages so that
> when a function for example doesn't get sufficient
> input, or cannot verity it, as those situations are
> common to many functions, an error function will be
> called to print a stderr message, rather than to have
> that coded over and over in all those functions.
>
> Only problem is, in order for debugging to be much
> less painful, the location where the problem happens
> must still be known. In the below zsh, the first line
> handles this by accessing the function stack - pretty
> clever, ey?
>
> Note: arrays in zsh are *not* zero-indexed, so the
> first element of funcstack is funcstack[1] and that is
> the current function! Ergo, funcstack[2] is the
> function that called the error handler!
>
> My question is, how do I do the same in Lisp (Elisp)?
>
> The zsh:
>
> no-file-msg () {
> local fun=$funcstack[2]
> local file=$1
> echo "$fun: no such file: $file" >&2
> }
>
> [1] http://user.it.uu.se/~embe8573/conf/.zsh/error
Pretty good discussion here, including access to the call stack:
http://emacs.stackexchange.com/questions/2310/can-functions-access-their-name
--
Dan Espen
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: factor out error message functions, access function stack to know location
2015-10-26 2:42 ` Dan Espen
@ 2015-10-27 0:27 ` Emanuel Berg
2015-10-27 1:50 ` Emanuel Berg
0 siblings, 1 reply; 4+ messages in thread
From: Emanuel Berg @ 2015-10-27 0:27 UTC (permalink / raw)
To: help-gnu-emacs
Dan Espen <despen@verizon.net> writes:
> Pretty good discussion here, including access to the
> call stack:
>
> http://emacs.stackexchange.com/questions/2310/can-functions-access-their-name
Using `backtrace-frame', this almost worked:
(defun function-stack ()
(cadr (backtrace-frame 3)) ) ;;; 3 = function-stack-caller (look below)
;;; 2 = function-stack
;;; 1 = cadr
;;; 0 = backtrace-frame
(defun function-stack-caller ()
(function-stack) )
(function-stack-caller) ; function-stack-caller! <success music here>
;; however...
(defun function-stack-embedded-caller ()
(if 'some-error-check (function-stack) ))
(function-stack-embedded-caller) ; if! so doesn't help...
--
underground experts united
http://user.it.uu.se/~embe8573
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: factor out error message functions, access function stack to know location
2015-10-27 0:27 ` Emanuel Berg
@ 2015-10-27 1:50 ` Emanuel Berg
0 siblings, 0 replies; 4+ messages in thread
From: Emanuel Berg @ 2015-10-27 1:50 UTC (permalink / raw)
To: help-gnu-emacs
Emanuel Berg <embe8573@student.uu.se> writes:
> Using `backtrace-frame', this almost worked ...
This excludes the "subr" functions - are they the
C ones?
Probably those are all you need to steer the flow to
the error communicator. And then it should work!
To quote the Captain of Titanic, "Now, nothing can
go wrong!"
(defun backtrace-to-non-subr-frame ()
(let ((i 6) ; offset determined by how *this* function is built
(f) )
(cl-loop while (setq f (cadr (backtrace-frame (incf i)))) do
(when (member (type-of (symbol-function f)) '(cons compiled-function))
(cl-return f) ))))
(defun function-stack-caller ()
(backtrace-to-non-subr-frame) )
;; (function-stack-caller) ; function-stack-caller
(defun function-stack-embedded-caller ()
(if 'some-error-check (backtrace-to-non-subr-frame) ))
;; (function-stack-embedded-caller) ; function-stack-embedded-caller
--
underground experts united
http://user.it.uu.se/~embe8573
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2015-10-27 1:50 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-10-26 1:17 factor out error message functions, access function stack to know location Emanuel Berg
[not found] <mailman.1053.1445821696.7904.help-gnu-emacs@gnu.org>
2015-10-26 2:42 ` Dan Espen
2015-10-27 0:27 ` Emanuel Berg
2015-10-27 1:50 ` Emanuel Berg
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).