Re^3: Goto-labels for exception handling?

For the rest I'm not sure what you are trying to tell me. (Probably not to use exceptions at all for errors? )

I was presuming you want to avoid using die/eval for exception handling.

Anyway, it is an interesting approach. But it is basically a shorthand for $errmsg = "message", goto ERRLABEL

Shorthand is fine. In this case, however, I think it hides something that the coder using your approach needs to be very aware of: That it is goto. The biggest problem with that being the dynamic scope. If the coder forgets this, the coder will discover the code's control flow jumping to unexpected places.

Comment on Re^3: Goto-labels for exception handling? Select or Download Code

Replies are listed 'Best First'.
Re^4: Goto-labels for exception handling? by LanX (Saint) on May 14, 2018 at 21:02 UTC
> The biggest problem with that being the dynamic scope. If the coder forgets this, the coder will discover the code's control flow jumping to unexpected places. Exactly and thank you for getting to the point. Contrary to die I can react to the case of a missing "receptor". But what if this supposedly missing labeled was already used somewhere up the dynamic scope? I think this could be solved... but I wanted to see if this wheel was already invented before. Unfortunately does already the mention of "goto" cause a lot of unrelated emotions ... :/ Cheers Rolf _{(addicted to the Perl Programming Language and ☆☆☆☆ :) Wikisyntax for the Monastery}	[reply]
Re^5: Goto-labels for exception handling? by RonW (Parson) on May 15, 2018 at 19:26 UTC
Personally, when it helps readability and maintainability, I have used `goto` - just very very rarely. Usually, where `goto` might be used, `last` can be used, though sometimes requires also using an error variable. As for "missing receptors", the only idea I have come up with is to make sure that all "goto" labels are unique. A major problem doing this is finding all the labels. (Maybe Perl::Critic can help with this.) Pre- or post- fixing labels can reduce collisions, but this is very tedious extra work. Maybe defining Pluggable keywords, for example, `throw` and `catch` could automate this.	[reply] [d/l] [select]