Veb silently fails to bind a handler when the result type is not veb.Result

[bradcypert]

Describe the bug

Hi, thanks for the work on V and Veb! I noticed some behavior with Veb that felt off and wanted to report it. If the return type of a Veb handler is not veb.Result (for example, it is !veb.Result), veb silently fails to bind the handler (the compilation succeeds, but when running Veb and hitting that URL, it 404s).

I know that !veb.Result is a bit of a weird example, but it would be nice if compiler indicated that we're doing something wrong instead of letting Veb silently fail to bind the handler. If we couldn't address it at compile time, I think runtime would be an okay solution, too.

Reproduction Steps

module main

import veb

const port = 8082
pub struct App {}

struct Context {
	veb.Context
}

@['/tasks/'; get]
//pub fn (app &App) get_task(mut ctx Context) !veb.Result {
pub fn (app &App) get_task(mut ctx Context) veb.Result {
	return ctx.text("Hello")
}

fn main() {
	mut app := &App{}
	veb.run_at[App, Context](mut app, port: port, timeout_in_seconds: 2) or {
		panic(err)
	}
}

In the above code example, there is a single handler function. This one works as expected, however, if you comment out the handler declaration and uncomment the one above it (or you could simply change the return type from veb.Result to !veb.Result), the code will compile and run, but the handler will not be registered and Veb will return a 404 when you try to access that route.

Expected Behavior

I would expect for V to give me a compiler error indicating that I am trying to use an invalid function type when registering a route handler which is invalid.

Current Behavior

Currently, V compiles the program successfully and it is runnable. There is no indication that Veb failed to bind that handler to that route, and when you make a request to that route, Veb returns a 404, never calling the handler.

Possible Solution

At compile-time, ensure that Veb handlers have the correction function signature and fail compilation if not. If this is not possible due to existing architecture, at runtime, we could log that a handler did not match the expected format and therefore it was not registered in veb.

Additional Information/Context

No response

V version

V 0.4.12 dc0b0f5

Environment details (OS name and version, etc.)

V full version	V 0.4.12 90fa8bc.dc0b0f5
OS	linux, Linux version 6.17.9-arch1-1 (linux@archlinux) (gcc (GCC) 15.2.1 20251112, GNU ld (GNU Binutils) 2.45.1) #1 SMP PREEMPT_DYNAMIC Mon, 24 Nov 2025 15:21:09 +0000
Processor	24 cpus, 64bit, little endian, AMD Ryzen AI 9 HX 370 w/ Radeon 890M
Memory	42.96GB/62.08GB
V executable	/home/brad/Projects/v/v
V last modified time	2025-12-14 15:50:46
V home dir	OK, value: /home/brad/Projects/v
VMODULES	OK, value: /home/brad/.vmodules
VTMP	OK, value: /tmp/v_1000
Current working dir	OK, value: /home/brad/Projects/vtask
Git version	git version 2.52.0
V git status	dc0b0f5
.git/config present	true
cc version	cc (GCC) 15.2.1 20251112
gcc version	gcc (GCC) 15.2.1 20251112
clang version	clang version 21.1.6
tcc version	tcc version 0.9.28rc 2025-02-13 HEAD@f8bd136d (x86_64 Linux)
tcc git status	thirdparty-linux-amd64 696c1d84
emcc version	N/A
glibc version	ldd (GNU libc) 2.42

Note

You can use the 👍 reaction to increase the issue's priority for developers.

Please note that only the 👍 reaction to the issue itself counts as a vote.
Other reactions and those to comments will not be taken into account.

[bradcypert]

I put together a potential fix for this and submitted a PR! Hope this helps :)