Improve parser error for bare except blocks with clear

[SupulHeshan]

Description

This PR improves the parser’s handling of bare except blocks by detecting a common misparse scenario where except { is interpreted as a dictionary context.

When semicolons appear inside what the parser assumes is a dict, we now:

• Correctly identify it as a bare except usage
• Point the error to the actual except line
• Emit a clear, user-friendly message guiding proper usage

This prevents confusing syntax errors and provides a graceful, actionable failure:

“Bare except is not supported. Use except Exception or except Exception as e”

Overall, this makes error reporting more precise, easier to understand, and safer for developers writing exception handling code.

examples:

Additionally, new test cases have been added.

[Copilot]

Pull request overview

Improves Jac parser diagnostics for the common misparse of bare except { ... } by attempting to detect the scenario and emit a clearer, actionable error message, with accompanying regression tests.

Changes:

• Add a parser heuristic to detect bare except { when the parser misinterprets { as a dict and then encounters semicolons.
• Emit a dedicated error message for bare except usage.
• Add a new fixture and unit test covering the new diagnostic.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.

File	Description
jac/jaclang/pycore/jac_parser.py	Adds bare-except misparse detection and emits a specialized error message.
jac/tests/compiler/test_parser.py	Adds a test asserting the bare-except diagnostic message.
jac/tests/compiler/fixtures/bare_except_error.jac	Adds a fixture that triggers the bare-except misparse path.

[Copilot]

Returning False from on_error causes Lark to re-raise the parse error, and JacParser.transform() will then log an additional generic "Unexpected token ..." error. That undermines the goal of a single clear bare-except diagnostic. Consider returning True with recovery (or setting a flag so the outer except jl.UnexpectedInput path skips logging) so only the bare-except message is reported.

Suggested change

	return False # Stop parsing gracefully
	return True # Error handled; allow Lark to recover without re-raising

[Copilot]

This test validates the new error message text, but it doesn't validate the key behavioral improvement described in the PR (pointing the error at the except line rather than the misparsed semicolon/dict context). Consider asserting the reported location (e.g., prog.errors_had[0].loc.first_line or a line <n> substring in pretty_print()) so regressions in the line/column mapping are caught.