Mailinglist Archive: yast-devel (81 mails)

< Previous Next >
Re: [yast-devel] About catching exceptions
  • From: Josef Reidinger <jreidinger@xxxxxxx>
  • Date: Thu, 22 Apr 2010 14:33:13 +0200
  • Message-id: <201004221433.14471.jreidinger@xxxxxxx>
Klaus Kaempf write:
* Martin Vidner <mvidner@xxxxxxx> [Apr 22. 2010 12:05]:
On Thu, Apr 22, 2010 at 11:36:58AM +0200, Klaus Kaempf wrote:
when calling functions known to raise exceptions, its always good
practice to enclose calls with begin ... rescue ... end and catch
exceptions locally.

Good that you bring it up because I think that you got it absolutely
wrong.

Unless you give more specific examples, this only creates more
problems by bypassing the generic, well-thought out system-wide
recue from.

Yes, you're right. I stand corrected.


CORRECT, unknown exceptions are handled by exception_trap in
http://gitorious.org/opensuse/yast-web-client/blobs/master/webclient/app/controllers/application_controller.rb

My problem is rest-service, not web-client.

Apparently the exception trap in rest-service is not sufficient.

See bnc#598794 where the rest-service errors out (presumably) because
of a permission error but this isn't shown in the rest-service logs.

This should be already fixed, what version of rest-service do you use? ( I add
logging of all exceptions)


And the web-client interpretes this as 503 Service Unavailable without
any hints about the real cause.

I think that problem is that miso catch too generic exception in users, because
out global catch handler if he gets 503 and in response is reported
insufficient permissions then it redirect to control panel and correctly print
message. Also clientException class has ability to print real cause in his
message method, because it understand out backend exceptions. You can try it
with e.g. tux user in appliance on almost all modules.
Reason why we use 503 and not 4** is that we want explicitelly know which error
code is thrown by lighttpd and which one is from our ruby code. Our ruby code
should always throw 503 and serialize information about problem in xml, where
is more informations.
So problem is not uncaught exception, but maybe somewhere other. How can I
reproduce this behavior?

Josef


Klaus
---
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG N├╝rnberg)



--
Josef Reidinger
YaST team
maintainer of perl-Bootloader, YaST2-Repair, parts of webyast
--
To unsubscribe, e-mail: yast-devel+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: yast-devel+help@xxxxxxxxxxxx

< Previous Next >
Follow Ups