Should error trigger help documentation?

Software G'MIC
1

I know, I been asking way too much questions while improving my +pal command.

I think I remember error triggering help documentation before. Shouldn’t it?

I have this snip for now:

	onfail
		closest_args=${rep_sug_args\ $m,,0,2,${-_pal_ids}}
		if same('$closest_args','00e0')
			e "ERROR: Invalid value '"$m"'. No close match found! Loading help file."
			h $0 q
		fi
		error "Invalid value '"$m"'. Expected one of (case-insensitive): "$closest_args

Which triggers a search for closest string to $m from the list of pal_ids, and if it doesn’t find any close match, it throws a help documentation for the user to find possible matches.

Of course, sometimes I don’t want error to trigger h. If a close match is found, it suggests arguments that are valid.

2

An error still display help documentation for the command.
Could you tell us in what case it doesn’t ?

3

Well, here’s a simple code:

#@cli foo_error_test :
#@cli : This is help documentation test.
foo_error_test:
error "test"

From cmd test, help documentation doesn’t show up:

C:\Windows\System32>gmic foo_error_test
[gmic]./ Start G'MIC interpreter (v.3.7.3).
[gmic] *** Error in ./ (file 'C:\Users\User\user.gmic', line #10) *** test
4

Ha yes, that’s because the help is displayed only when a check command does not succeed, which means one command has been called with wrong arguments.
error is a more general command that can be used simply to tell something wrong happens despite the command has been called correctly (in which case the user doesn’t want necessarily the help to be displayed).

If you really want to display the command help for a specific error, you’ll have to use check instead of error, but this implies a false condition must be passed to check.

5

Yes. But, a issue arise when it’s like this:

#@cli foo_error_test :
#@cli : This is help documentation test.
foo_error_test:
l[] {
	error "test"
	onfail
		check $1==1
}

No help documentation here:

C:\Windows\System32>gmic foo_error_test 0
[gmic]./ Start G'MIC interpreter (v.3.7.3).
[gmic] *** Error in ./foo_error_test/*local#10/ (file 'C:\Users\User\user.gmic', line #13) *** Command 'check': Expression '0==1' is false.
6

That’s because the local block is considered as an anonymous command (with no name), so when the error is thrown by check, the interpreter does not consider the parent command. That is something I may change for future releases.

Workaround: Define a variable is_error=1 after the onfail, and does the check after the local block, only if is_error==1.

7

Like this?

#@cli foo_error_test :
#@cli : This is help documentation test.
foo_error_test:
is_error=0
l[] {
	error "test"
	onfail
		is_error=1
}

if $is_error
	check $1==1
fi

Output:

C:\Windows\System32>gmic foo_error_test 0
[gmic]./ Start G'MIC interpreter (v.3.7.3).
[gmic] *** Error in ./foo_error_test/*if#14/ (file 'C:\Users\User\user.gmic', line #19) *** Command 'check': Expression '0==1' is false.

Yeah, I do think both check/error could use a slight more options. Maybe both could use a 1 to force help documentation as second argument.

8