Hans,

I've just committed an improved PerlMate. PerlMate now causes perl to load exception_handler.pm before executing the user code. exception_handler.pm overrides CORE::GLOBAL::die to format unhandled exceptions and print them to the file descriptor given by the environment varibale TM_ERROR_FD. This let's us manipulate the actual exception objects instead of just their string representations.

The implementation is very basic, as I have no actual Perl programming experience. But it handles `die "Sometext";` just fine. I don't know how it will react to the throwing of except objects.

Perhaps you can look this over, and let me know what you think?

-Alex

On 11/28/06, Hans-Joerg Bibiko bibiko@eva.mpg.de wrote:

Hi,

here is a **suggestion** to format Perl's error messages a bit better:

-some highlighting stuff -hyperlinks for errors given as 'at FILE line X' (works with current script and also for errors coming from other scripts)

PLEASE forgive my Ruby syntax! I'm just learning ;)

BTW Would it be worth to think about a general css for outputting errors as HTML coming from scriptmate?

Cheers,

Hans

---

For new threads USE THIS: textmate@lists.macromates.com (threading gets destroyed and the universe will collapse if you don't) http://lists.macromates.com/mailman/listinfo/textmate

Hans,

The the reason we don't want to handle errors that were throw in eval blocks is the reason you mentioned. Typically, the user handles the error themself. But it is bad that $@ refers to exception_handler.pm line 34 after a die. I think we can fix this somehow.

Also, for things that are errors, they should be written to TM_ERROR_FD. Something written to STDERR that isn't an error should be left alone. Would it be possible to filter STDERR from a perl module that we can load using the -m switch?

- Alex

On Nov 30, 2006, at 2:06 AM, Hans-Joerg Bibiko wrote:

Hi Alex

On 30 Nov 2006, at 09:15, Alexander Ross wrote:

...

I've just committed an improved PerlMate. PerlMate now causes perl to load exception_handler.pm before executing the user code. exception_handler.pm overrides CORE::GLOBAL::die to format unhandled exceptions and print them to the file descriptor given by the environment varibale TM_ERROR_FD. This let's us manipulate the actual exception objects instead of just their string representations.

The implementation is very basic, as I have no actual Perl programming experience. But it handles `die "Sometext";` just fine. I don't know how it will react to the throwing of except objects.

I just checked your exception handler. It works fine as long as you use 'die' mot in a 'eval' environment. In Perl you often write your own handler like this:

Example: _______________________ #!/usr/bin/perl -w

$a = 5; $b = -1;

eval { $c = $a / $b; die "Denominator cannot be negative" if ($b < 0); };

print "Run-time error: $@"; _________________________

If I run this the 'die' output never reaches your exception handler because of

if($^S) { CORE::die($@); }...

Perl's $@ refers now to exception_handler.pm line 34 and this is not what I want to see.

Why did you choose this 'if clause' to call CORE::die?

If you leave it out and take only the else clause it works. (?)

On the other hand you have a small typo in line 55 of exception_handler.pm

corrected: print TM_ERROR_FD '<tr><td>in <a href="txmt://open?' . $url . '&line=' . $line . '"> ' . $display_name . "</a> at line $line<td></ tr>\n" ;

because:

print '$line' will print "$line" not the content of the variable $line.

###########

I wrote a small error/warning formatter in my posted perlmate.rb. Would it better to use TM_ERROR_FD instead of

class PerlMate < ScriptMate def filter_stderr(str) ... ?

-Hans

---

For new threads USE THIS: textmate@lists.macromates.com (threading gets destroyed and the universe will collapse if you don't) http://lists.macromates.com/mailman/listinfo/textmate

On Nov 30, 2006, at 6:07 PM, Hans-Joerg Bibiko wrote:

Alex,

...

The the reason we don't want to handle errors that were throw in eval blocks is the reason you mentioned. Typically, the user handles the error themself. But it is bad that $@ refers to exception_handler.pm line 34 after a die. I think we can fix this somehow.

Try the attached exception_handler.pm.

Hmm, can't Perl exception catching be done the way we do it in Ruby? My Perl is rusty but a close translation would be something like the following (I think):

END { if ($@) { # we are exiting with an exception here... } }

James Edward Gray II

On 1 Dec 2006, at 07:49, Alexander Ross wrote:

James,

I tried this out but couldn't get it to work. $@ wasn't set when the END block was called.

? Did you tried out my version with 'exit(1) if(!$^S);'? If yes could you please send me an example script which doesn't work.

What do you mean with: "$@ wasn't set when the END block was called"? I'm dealing with $^S.

The good news is if we are in an eval block, exception_handler::die can call Carp::croak[1]. Which "dies of errors (from perspective of caller)".

Yes, to use Carp is a very good idea. You can call in perlmate.rb

def args ["-I#{e_sh(Pathname.new(ENV['TM_BUNDLE_SUPPORT']) + "PerlMate")}", "-Mexception_handler", "-MCarp=verbose"] end

and write within the 'sub die' (excep... .pm)

print TM_ERROR_FD "<p>".Carp::longmess()."</p";

which will print something like

at /Users/.../untitled.pl line 8 eval {...} called at /Users/.../ untitled.pl line 6

-Hans

Alex

Now I'm able to distinguish separately:

-syntax errors (missing colons etc.) via $SIG{__DIE__} = &syserror; -system errors via $SIG{__DIE__} = &syserror; -system warnings (useless use of etc.) via $SIG{__WARN__} = &syswarn; -user-defined warnings (warn("foo";) via ::warn -die statements if it occurs within eval block message will printed out and the program runs further else message will printed out and the program will be aborted due to exception

In order to hide stderr for perlmate you have to write in perlmate.rb

class PerlMate < ScriptMate def filter_stderr(str) "" end end

I don't use your 'sub id' except for 'sub warn'. Here everything should be clear. Otherwise I trust Perl's error messages more than 'caller($level);'. Esp. for the case if Perl's message contains more than one link like Carp::longmess() it often does.

Comments?

This code is up to now very redundant. It's only for testing!

-Hans

Hans,

I tried the version with `exit(1) if(!$^S);` but it didn't mimic the true behavior of die. Specifically, if die is called inside of eval, the $@ value is not set up appropriately.

- Alex

On Dec 1, 2006, at 12:52 AM, Hans-Joerg Bibiko wrote:

On 1 Dec 2006, at 07:49, Alexander Ross wrote:

...

James,

I tried this out but couldn't get it to work. $@ wasn't set when the END block was called.

? Did you tried out my version with 'exit(1) if(!$^S);'? If yes could you please send me an example script which doesn't work.

What do you mean with: "$@ wasn't set when the END block was called"? I'm dealing with $^S.

...

The good news is if we are in an eval block, exception_handler::die can call Carp::croak[1]. Which "dies of errors (from perspective of caller)".

Yes, to use Carp is a very good idea. You can call in perlmate.rb

def args ["-I#{e_sh(Pathname.new(ENV['TM_BUNDLE_SUPPORT']) + "PerlMate")}", "-Mexception_handler", "-MCarp=verbose"] end

and write within the 'sub die' (excep... .pm)

print TM_ERROR_FD "<p>".Carp::longmess()."</p";

which will print something like

at /Users/.../untitled.pl line 8 eval {...} called at /Users/.../ untitled.pl line 6

-Hans

---

For new threads USE THIS: textmate@lists.macromates.com (threading gets destroyed and the universe will collapse if you don't) http://lists.macromates.com/mailman/listinfo/textmate

Hi Alex,

after 'sleeping' the whole weekend about that here my suggestion:

####################### - if you write BEGIN { *CORE::GLOBAL::die = &__PACKAGE__::die; }

then we run into problems if the 'die' is called from inside a package, because you get the error message unknown subroutine for '__PACKAGE__::die'

That's why I tried: BEGIN { $SIG{__DIE__} = &die;

######################## - we also have to catch a 'warn' statement within an 'eval block'

That's why include the subroutine warn. Otherwise you get an error message for an unknown routine.

######################## - I change the id subroutine to get really the line which emitted the exception. Example:

#!/usr/bin/perl -w

use Foundation;

$f= NSString->foo("H");

will write something like this: **** ERROR **** PerlObjCBridge: sendObjcMessage: Can't get NSMethodSignature for message "foo" **** ERROR **** PerlObjCBridge: error sending message foo at /System/ Library/Perl/Extras/5.8.6/darwin-thread-multi-2level/ PerlObjCBridge.pm line 230.

But here I don't know which line of my script emitted this error. After my changes at the subroutine id now I get: **** ERROR **** PerlObjCBridge: sendObjcMessage: Can't get NSMethodSignature for message "foo" **** ERROR **** PerlObjCBridge: error sending message foo at /System/ Library/Perl/Extras/5.8.6/darwin-thread-multi-2level/ PerlObjCBridge.pm line 230. in untitled.pl at line 5

What I'm done here is to call 'caller' as long as the return is defined; go one level back and ask whether the exception/warn was called from inside of an eval block.

######################## - if 'die' is called from inside of 'eval' the handler writes the message and the script is running further exit($!) if (!$^S);

######################## - to output the real content of $message I wrote a tiny htmlize subroutine

######################## - to avoid redundancy I wrote two tiny subroutines for file name checking and printing

######################## - to avoid an error on a closed file handle if warn and die occur within an eval block I specified BEGIN { $SIG{__DIE__} = &die; my $error_fd = $ENV{"TM_ERROR_FD"}; open (TM_ERROR_FD, ">&=$error_fd"); }

END { print TM_ERROR_FD "</div>"; close (TM_ERROR_FD); }

########################

I tested it several times and it seems that it works. Comments?

All the best,

Hans