Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Morbo issues with Mojolicious 9.34 (change in Mojo/Server.pm) #2110

Closed
daleif opened this issue Sep 18, 2023 · 1 comment · Fixed by #2111
Closed

Morbo issues with Mojolicious 9.34 (change in Mojo/Server.pm) #2110

daleif opened this issue Sep 18, 2023 · 1 comment · Fixed by #2111

Comments

@daleif
Copy link

daleif commented Sep 18, 2023

  • Mojolicious version: 9.34
  • Perl version: 5.34
  • Operating system: Ubuntu 22.04

Steps to reproduce the behavior

Inspired by the example in #2094

use v5.34;
use Mojolicious::Lite -signatures;
$test;
app->start;

Then run with morbo

Expected behavior

Something like

Web application available at http://127.0.0.1:3000
Can't load application from file "path to script": Global symbol "$test" requires explicit package name (did you forget to declare "my $test"?) at "path to script" line 3.
Compilation failed in require at (eval 93) line 1.

Actual behavior

Instead I get

Web application available at http://127.0.0.1:3000
Can't load application from file "path to script": "path to script" did not return a true value at path/lib/perl5/Mojo/Server.pm line 59.

Which makes debugging ones own mistakes rather hard.

Note that the problem is related to #2097 which changed

    my $app = eval "package Mojo::Server::Sandbox::@{[md5_sum $path]}; require \$path";

in Mojo/Server.pm into

    my $app = eval "package Mojo::Server::Sandbox::@{[md5_sum $path]}; do \$path";

(plus some extra checks).

Manually changing do back into require makes morbo behave like normal.

@daleif
Copy link
Author

daleif commented Sep 18, 2023

I'm wondering if it should make sense to run both the do and the require version. Such that the latter is run if the first did not return a true value.

@kraih kraih added bug and removed bug labels Sep 19, 2023
haarg added a commit to haarg/mojo that referenced this issue Sep 19, 2023
When switching from loading an application from using require to using
do, the error was still trying to be captured after a surrounding eval.
This error would always be empty, because the error from the do was not
rethrown. It would still result in an undef application, so an error
would be thrown, but it would not include the actual compile error.

Change the do call inside the eval to throw an error if no application
is returned. The error is then recaught outside the eval. Also add a
test that shows that the real compilation error is included in the
output.

Fixes mojolicious#2110
haarg added a commit to haarg/mojo that referenced this issue Sep 19, 2023
When switching from loading an application from using require to using
do, the error was still trying to be captured after a surrounding eval.
This error would always be empty, because the error from the do was not
rethrown. It would still result in an undef application, so an error
would be thrown, but it would not include the actual compile error.

Change the do call inside the eval to throw an error if no application
is returned. The error is then recaught outside the eval. Also add a
test that shows that the real compilation error is included in the
output.

Fixes mojolicious#2110
@mergify mergify bot closed this as completed in #2111 Sep 19, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants