jeffery posted:

he has an exception programmed in the a.i. to override the blockade of his suicide

brand engager posted:

is that dude a bot and/or having a psychotic break

HoboMan posted:

my code as it stands

C# code:

public IHttpActionResult SubmitForm([FromBody]string json)
{
    var purchaseOrder = JsonConvert.DeserializeObject<PurchaseOrder>(json, defaultSettings);
    using (var connection = new SqlConnection(ConfigurationManager.ConnectionStrings["myDatabase"].ConnectionString))
    {
        try
        {
            // submit the info into the database
        }
        catch(SqlException e)
        {
            logger.error(connection , "Exception saving purchase order", e);
            return InternalServerError();
        }
    }
    Task.Run( () =>
        {
            using (var connection = new SqlConnection(ConfigurationManager.ConnectionStrings["myDatabase"].ConnectionString))
            {
                try
                {
                    // send email
                    logger.debug(connection , "Sent email");
                }
                catch(Exception e)
                {
                    logger.error(connection , "Exception sending email", e);
                }
            }
        });
    return Ok();
}

"Sent email" will get logged, but if i hard code an exception in the try block "Exception sending email" will not get logged.

e: i literally just added the using and Task.Run blocks around the existing try-catch that was there.

e2: i forgot to include the try-catch for the json parsing, but you get the idea

HoboMan posted:

my code as it stands

C# code:

public IHttpActionResult SubmitForm([FromBody]string json)
{
    var purchaseOrder = JsonConvert.DeserializeObject<PurchaseOrder>(json, defaultSettings);
    using (var connection = new SqlConnection(ConfigurationManager.ConnectionStrings["myDatabase"].ConnectionString))
    {
        try
        {
            // submit the info into the database
        }
        catch(SqlException e)
        {
            logger.error(connection , "Exception saving purchase order", e);
            return InternalServerError();
        }
    }
    Task.Run( () =>
        {
            using (var connection = new SqlConnection(ConfigurationManager.ConnectionStrings["myDatabase"].ConnectionString))
            {
                try
                {
                    // send email
                    logger.debug(connection , "Sent email");
                }
                catch(Exception e)
                {
                    logger.error(connection , "Exception sending email", e);
                }
            }
        });
    return Ok();
}

"Sent email" will get logged, but if i hard code an exception in the try block "Exception sending email" will not get logged.

e: i literally just added the using and Task.Run blocks around the existing try-catch that was there.

e2: i forgot to include the try-catch for the json parsing, but you get the idea

HoboMan posted:

but i am also that guy!!!

Night Shade posted:

Bet logger is getting disposed when the request completes, and the task is silently discarding an object disposed exception

HoboMan posted:

my code as it stands

"Sent email" will get logged, but if i hard code an exception in the try block "Exception sending email" will not get logged.

e: i literally just added the using and Task.Run blocks around the existing try-catch that was there.

e2: i forgot to include the try-catch for the json parsing, but you get the idea

Zlodo posted:

phonetically Q is butt in french so it makes sense

Symbolic Butt posted:

lol

current q report: working with dates feels really nice but q is hella weakly typed so this is biting me a lot

like check this out

code:

q) handle_variable:hopen `:localhost:5010     / connects to a q server at localhost:5010 and assigns to handle_variable
q) handle_variable "2i+2i+2i"                 / you can execute q code at the server this way
6i
q) handle_variable                            / it's... actually just an int32?
428i
q) 428i "2i+2i+2i"                            / so you can also execute at the server this way. applying a string to the int32.
6i

redleader posted:

this goes well beyond "weakly typed" and into "insanely typed"

HoboMan posted:

my code as it stands

C# code:

public IHttpActionResult SubmitForm([FromBody]string json)
{
    var purchaseOrder = JsonConvert.DeserializeObject<PurchaseOrder>(json, defaultSettings);
    using (var connection = new SqlConnection(ConfigurationManager.ConnectionStrings["myDatabase"].ConnectionString))
    {
        try
        {
            // submit the info into the database
        }
        catch(SqlException e)
        {
            logger.error(connection , "Exception saving purchase order", e);
            return InternalServerError();
        }
    }
    Task.Run( () =>
        {
            using (var connection = new SqlConnection(ConfigurationManager.ConnectionStrings["myDatabase"].ConnectionString))
            {
                try
                {
                    // send email
                    logger.debug(connection , "Sent email");
                }
                catch(Exception e)
                {
                    logger.error(connection , "Exception sending email", e);
                }
            }
        });
    return Ok();
}

"Sent email" will get logged, but if i hard code an exception in the try block "Exception sending email" will not get logged.

e: i literally just added the using and Task.Run blocks around the existing try-catch that was there.

e2: i forgot to include the try-catch for the json parsing, but you get the idea

AWWNAW posted:

you should look to use HostingEnvironment.QueueBackgroundWorkItem
as described in this lovely blog post https://blogs.msdn.microsoft.com/webdev/2014/06/04/queuebackgroundworkitem-to-reliably-schedule-and-run-background-processes-in-asp-net/ which just happens to be about sending email too

any time you're doing "long running" work in ASP.NET (you never should) you're subject to the AppPool being recycled and all that poo poo. MS realized people were not going to figure out this is a bad idea so they added this

Symbolic Butt posted:

ColTim posted:

Is that the one where if you negate it the code gets run async?

brap posted:

- Scheduled work items are not guaranteed to ever execute, once the app pool starts to shut down, QueueBackgroundWorkItem calls will not be honored.

lol. deal with this by fixing the mail server if you possibly can. otherwise if you want things to actually get delivered it sounds like you need to store the pending emails in a persistent queue.

Soricidus posted:

ctps: somehow I’ve ended up writing a perl script

JawnV6 posted:

so every little thing where the professor was trying to explain, say, flow control with a for() loop, this guy would break down in tears at how much heavy lifting the language was doing for him

mod saas posted:

joy or frustration?

ratbert90 posted:

from what I have been told:

Perl is good if you want to write a script that uses regex or does a lot of math.

I think that’s about it.