Testing $@ is not the best way to determine an exception occurred. I'd
recommend Syntax::Keyword::Try as it handles all the edge cases for you,
but otherwise this gets you most of the way:
if (eval { ...; 1 }) {
# success
} else {
my $err = $@;
}
And make sure you log errors and rethrow any exceptions you do not handle.
You will want to see the error logging later.
-Dan
On Wed, May 8, 2019 at 1:18 PM Luc Larochelle <llaroche...@gmail.com> wrote:
> This works just as expected. In my case I wanted to catch foreign key
> constraints. Now I'm prepared for the critics, I'll post my "del" route,
> it's from an Lite application serving a web app. I wonder if I'm doing
> things the right way.
>
> I tried to make it idempotent for GET, POST, PUT & DEL but since I have to
> deal with little exceptions in the given routes, they all have their
> definitions. For instance, :id is *id in the GET route, since its principal
> task is to display the whole table. The helpers though (model ?) are not
> dealing with exceptions at all and are used to execute simple tasks to the
> db given the params feeded by the routes.
>
> I'm very opened to discuss all of this, this has to be my most serious
> project since I started using Mojolicious and I'm learning frontend coding
> on-the-fly ...
>
> helper insertOne => sub {
> my ($c,$table) = @_;
> $c->sqlite->db->insert($table, $c->element);
> };
>
>
> helper deleteOne => sub {
>
> my ($c,$table,$param) = @_;
> $c->sqlite->db->delete($table, {$tables->{$table} => $param});
> };
>
>
>
> del '/api/select/:table/:id' => sub {
>
> my $c = shift;
> if ($c->selectOne($c->param('id'))) {
> eval { $c->deleteOne($c->param('table'),$c->param('id')) };
> unless($@) {
> $c->render(status => 200, json => {message => $c->param('id') .
> $messages->{'Del'}});
> } elsif ($@ =~ /FOREIGN KEY constraint failed/) {
> $c->render(status => 400, json => {message => $c->param('id') .
> $messages->{'FK'}});
> }
> } else {
> $c->render(status => 404, json => {message => "Not found"});
> }
>
> };
>
>
>
> On Wednesday, 20 March 2019 11:58:04 UTC-4, Luc Larochelle wrote:
>>
>> Thanks ! Maybe I read only the sections and bold titles :)
>>
>> I'll have a second look.
>>
>>
>> On Monday, 18 March 2019 12:35:48 UTC-4, Dan Book wrote:
>>>
>>> As mentioned in the documentation: "Any database errors will throw an
>>> exception as RaiseError is automatically enabled, so use eval or
>>> Try::Tiny <https://metacpan.org/pod/Try::Tiny> to catch them. "
>>>
>>> This is the standard way to handle errors in Perl. Syntax::Keyword::Try
>>> is also a nicer interface if you can use keyword plugins (perl 5.14+).
>>>
>>> -Dan
>>>
>>> On Mon, Mar 18, 2019 at 10:00 AM Luc Larochelle <llaro...@gmail.com>
>>> wrote:
>>>
>>>> Hello Veesh, well to me that looks like "eval" , right ? I meant is
>>>> there a way with Mojo::SQLite to check errors ?
>>>>
>>>> On Saturday, 16 March 2019 15:12:11 UTC-4, Veesh Goldman wrote:
>>>>>
>>>>> Does Try::Tiny strike your fancy? It'll put the error into $_ in the
>>>>> catch block.
>>>>>
>>>>> Short of that, I'm fairly certain it'll crash your thread if it fails.
>>>>>
>>>>> On Fri, Mar 15, 2019, 10:22 PM Luc Larochelle <llaro...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hello everyone,
>>>>>>
>>>>>> While a 'select' statement can be double checked by the presence of
>>>>>> the returned data, how can I confirm that statements such as 'insert' ,
>>>>>> 'update' or 'delete' are successful ?
>>>>>>
>>>>>> For instance, using SQL::Abstract and some helpers
>>>>>>
>>>>>> helper insertOne => sub {
>>>>>> my ($c,$table) = @_;
>>>>>> $c->sqlite->db->insert($table, $c->element);
>>>>>> };
>>>>>>
>>>>>>
>>>>>>
>>>>>> I've seen in the documentation that one could *eval* and look into
>>>>>> $@ , but is there a more "inline" way to do this ?
>>>>>>
>>>>>> Cheers !
>>>>>>
>>>>>> Luc
>>>>>>
>>>>>> --
>>>>>> You received this message because you are subscribed to the Google
>>>>>> Groups "Mojolicious" group.
>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>> send an email to mojolicious...@googlegroups.com.
>>>>>> To post to this group, send email to mojol...@googlegroups.com.
>>>>>> Visit this group at https://groups.google.com/group/mojolicious.
>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>
>>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Mojolicious" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to mojolicious...@googlegroups.com.
>>>> To post to this group, send email to mojol...@googlegroups.com.
>>>> Visit this group at https://groups.google.com/group/mojolicious.
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>> --
> You received this message because you are subscribed to the Google Groups
> "Mojolicious" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mojolicious+unsubscr...@googlegroups.com.
> To post to this group, send email to mojolicious@googlegroups.com.
> Visit this group at https://groups.google.com/group/mojolicious.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/mojolicious/e3480fbb-d830-461f-b644-33f3de62db18%40googlegroups.com
> <https://groups.google.com/d/msgid/mojolicious/e3480fbb-d830-461f-b644-33f3de62db18%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
--
You received this message because you are subscribed to the Google Groups
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to mojolicious+unsubscr...@googlegroups.com.
To post to this group, send email to mojolicious@googlegroups.com.
Visit this group at https://groups.google.com/group/mojolicious.
To view this discussion on the web visit
https://groups.google.com/d/msgid/mojolicious/CABMkAVXOF03tv%3Dmh7LXqDErXWKno%3D7grzo0e0DNKRYfxGr3Vkw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
