feat: case insensitive request methods#3
Conversation
Output Error Message to `stderr`
hars-21
left a comment
There was a problem hiding this comment.
Thanks for the PR!
Could you please revert the Cargo.toml changes that bump the version and add your name to the authors field?
We manage versioning and releases separately and the authors field is maintained by the project maintainers.
Everything else looks good and I'll continue the review once that's updated.
Revert Cargo.toml metadata changes.
|
@hars-21 -- revert completed. Thanks, AKG. |
hars-21
left a comment
There was a problem hiding this comment.
I feel the logger module is a bit overkill for now. It might fail in some edge cases. So, I recommend using eprintln! macro instead of logger to directly print error. This issue requires discussion as there are multiple ways it can be implemented.
|
No problem. I will make the necessary corrections and update this PR. I was just trying to keep the existing functionality where in interactive mode, errors were printed to STDOUT. I am curious what edge cases you came across. |
Replace logger module with eprintln!() macro.
|
@hars-21 -- Replaced logged module with eprintln!() macro. |
When STDIN is TTY then errors go to STDOUT. You can test it by running Also, I am planning to add a tokenization layer which can fully fix this issue and support redirections as well in REPL. |
stderr
Currently,
reqshroutes error messages directly to stdout. While this works for displaying text on a terminal, it creates significant issues for automation, scripting, and shell pipelines. When a command fails, downstream scripts expect clean data from stdout rather than having to parse error strings or stack traces.The solution
This PR standardizes the application's output streams by ensuring that error diagnostics and execution failures are explicitly routed to
stderr. This keepsstdoutreserved strictly for successful data payloads, following standard CLI design principles.Bonus
reqshcan be lower/UPPER/MiXEd case and still work.